按关键词阅读：
编辑导读：消息中心作为系统信息的集散地，是系统与用户之间对话的基础。本文作者梳理了B端产品的消息中心数据流逻辑，希望对你有帮助。
文章插图
【 通知|B端产品设计：消息中心数据流逻辑】此文是本人从事产品经理工作以来，在设计B端企业内部系统消息中心相关功能时的一些思考，偏重数据流逻辑梳理，内容讨论展开多基于B端企业内部产品的消息场景。
一、定位、来源及作用消息中心作为系统信息的集散地，是系统与用户之间对话的基础。通过这个集散地，系统可以向用户传达包括且不仅局限于以下信息：
特别地，针对IM类产品，消息更多是用户与用户之间的对话信息，此类不在这里讨论。
不同的系统，因其产品定位不同，其消息中心数据来源和作用也不相一致。一般系统的消息来源在大方向上可以分为2类，一类是站内消息，一类是站外消息。
- 站内消息：指系统本身触发的消息内容，涵盖系统公告、待办提醒等；用于向用户传达其在当前系统需要执行或知悉的信息，用户行为一般限制在当前系统内，不与外界系统产生信息交流或动作交互。当然，也有一些消息来源是站内，但用户需要在外界系统完成信息处理的，不过相对比较少。
- 站外消息：指外部系统通过当前系统分发机制给用户同步的提醒信息；用户在收到此类消息，正常都可以通过当前系统链接到对应外部系统去完成信息处理动作，用户行为不局限于当前系统内，会频繁与外界系统产生信息交流或动作交互。
文章插图
例如，某司针对HRBP群体有一个工作台系统，用于处理HRBP工作事务，其消息中心定位是作为HRBP获取与其相关的工作事务通知提醒的信息集散地。所以该消息中心的消息来源便不仅有工作台本身，同时支持外部系统消息接入，如招聘系统接入招聘入职相关消息、360评估系统接入评估提醒相关消息等。用户可以通过这个系统获知所有工作相关的信息，并有针对性地对消息进行处理，而不再需要登录其他40+个HR相关系统获取信息。
所以，在开展消息中心设计之前，我们一定是需要明确这个功能的定位和数据范围，也就是梳理清楚战略层和范围层的内容，在这之后才能更好地完善功能逻辑和甄别需求。
二、消息流逻辑无论站内还是站外消息，在消息数据进入消息中心之后，会通过其分发机制触发给相关用户，用户即可在前端系统的消息盒子中查看到具体的消息内容；如果涉及到转发外部系统提醒的，如邮件中心或短信中心等，则会由消息中心向对应系统发起请求，并触发短信或邮件至用户处。可见下面时序图：
文章插图
我们可以看到，上述时序图涉及消息来源、消息中心、消息盒子和外部通知系统。
- 消息来源：含站内消息和站外消息，可以是当前系统本身的提醒或公告，也可以是外部其他系统的提醒。
- 消息中心：当前系统的底层逻辑，用以消息分发、请求外部通知的集中处理模块。
- 消息盒子：当前系统的消息中心外在表现，用以与用户交互和信息交流的功能模块；用户可以在消息盒子中查阅所有与其相关的消息。
- 外部通知：部分需强提醒或对时效性要求高的消息，会通过一些外部系统辅助消息及时快速触达，使得用户没有登录当前系统也能获知消息。此类外部通知系统多指邮件服务中心、短信服务中心、企业微信、飞书、钉钉等。
文章插图
消息来源信息会先进入待发送池排队，形成一个消息队列，遵循先进先出规则。消息中心会根据每个消息中所携带的接收对象ID进行消息分发，即将该消息发送至对应用户的消息盒子中；同时根据提醒方式判断是否调用外部通知系统启动其他提醒方式。外部通知系统一般有固定的消息模板和提醒逻辑，消息中心需要将提醒对象和应用模板ID、对应模板参数同步给外部通知系统，由外部通知系统判断并触发消息模板进行通知。
稿源：(人人都是产品经理)
【傻大方】网址：/c/1201b0X62021.html
标题：通知|B端产品设计：消息中心数据流逻辑