您好 Discourse 团队（以及社区！），
这是对 Discourse vs Salesforce Community vs Slack 的后续跟进。
在 Markforged，我们一直在讨论为我们的渠道合作伙伴（经销商）和客户建立社区。目前，几乎任何事物被采纳的关键业务要求之一是它能与 Salesforce 良好协作，以获得“客户 360 度视图”。
目前，我的一些同事为一部分客户启动了一个测试版 Salesforce 社区，我们正在观察其进展情况。我们希望通过为我们的渠道合作伙伴和/或不同的用户组启动一个独立的论坛来进行 A/B 测试，以提供基于证据的决策机会，并为将正确的数据/元数据从外部平台导入 Salesforce 的集成工作提供潜在的理由，如果这些平台能提供比 Salesforce 原生平台明显更优越的结果。
我可能错了，Discourse 可能不会像我想象的那样带来巨大的改变——但我希望通过数据来证明我错了，而不是因为它在功能/参与者体验方面被视为与 Salesforce 社区产品相当，并且被认为实施起来更费力，从而一开始就被排除在外。我的初步假设是，这两种观点都不准确。
在查看有关 Salesforce<0xE3><0x80><0x88><0xE3><0x80><0x89>Discourse 集成的帖子时，除了我同事上面链接的帖子外，我没有看到任何最新的内容。我很想听听大家关于集成以及你们实施了什么以及在此过程中遇到的障碍。
@awesomerobot 由于我们在上一个帖子中没有回答您的问题，我在这里回答。一个理想的 Salesforce<0xE3><0x80><0x88><0xE3><0x80><0x89>Discourse 桥梁将：
- 使用 Salesforce SSO 登录进行身份验证，以便登录与 SFDC 中的联系人匹配
- 将用户的帖子推送到 SFDC 的“动态”中：帖子内容 + 帖子链接，包括附件链接（我们可能会在我们的 S3 上实现附件托管）
- 将 Discourse 用户个人资料摘要统计信息与联系人字段同步，以及徽章，以便我们可以在 SFDC 中运行社区活动的报告
- 能够从 SFDC 设置/推送组权限/标记到 Discourse，以便 Salesforce 业务逻辑规则影响社区主题可见性等…（这个人是渠道合作伙伴的技术支持人员，他可以看到 X 个主题，这是客户，他只能看到 Y 个主题，等等…）
另一个常见的内部反对意见是，这将成为“另一个需要与 Salesforce 同步的数据库”，我想就此获得指导/帮助来反驳，考虑到 SSO 和上述桥接功能…这似乎会相当同步，对吧？
期待大家的意见！
<0xE3><0x80><0x88>/rant>
