蝉鸣 CRM 低代码与工作流：让业务变化落在正确的层
不是所有需求都应拖拽，也不是每次变化都值得重新开发。关键是识别变化类型。
企业经常提出看似很小的需求：客户增加行业字段，选择产品后自动带出价格，合同超过折扣需要审批，新建项目时同步生成任务。如果全部写进页面代码，小改动也要发布；如果全部交给低代码，权限、金额和状态又可能失控。
核心判断
字段和布局交给自定义应用，当前页面的交互交给事件流，跨人员的状态推进交给工作流，必须始终一致的规则交给领域代码。
从需求性质选择实现层
应用矩阵：先划清业务边界
应用管理不是简单的菜单集合，而是低代码建模的第一层边界。当前页面能够统一管理 CRM、OA、进销存、订单、运输、仓储、质量、制造、教育和旅游等应用。每个应用拥有自己的模块、配置和发布范围，同时复用组织、租户、字典、流程与权限等平台能力。
这种组织方式让企业可以从一个 CRM 场景开始，逐步增加教育、旅游或供应链模块，而不必为每个行业重新搭建账号、权限和基础设施。应用负责隔离业务语境，模块负责描述业务对象，表单和流程再承接具体变化。
自定义应用与自定义表单：描述“业务要记录什么”
应用组织业务边界，模块描述客户、项目、资产等对象，页面和表单决定字段、布局、校验与展示。教育机构可以为客户增加意向课程和校区，旅游企业可以增加目的地、人数和出行日期，而稳定的客户身份与联系人关系仍复用 CRM。
字段配置应包含类型、是否必填、默认值、字典、长度和可见范围。新增字段容易，真正重要的是生命周期：字段改名是否影响接口，删除前是否仍有历史数据，枚举变化如何兼容旧记录，导入导出是否使用同一语义。
同一个业务模块往往不只有一张编辑表单。列表页面、新增表单、编辑表单、列表表头、导入导出表头、详情页和查重表单承担不同任务。系统将这些配置分别管理，并允许设置默认配置和授权范围，避免用一份页面定义强行覆盖所有操作场景。
可视化设计器：把字段、业务组件与布局组合起来
设计器左侧提供字段组件、业务组件、页面组件和布局组件，中间画布表达真实表单结构，右侧配置当前组件属性。以客户表单为例，客户名称、编码、成交状态、来源、行业、手机号和金额字段可以与联系人、跟进记录、合同、回款、商机、发票、附件及操作记录组合在同一客户视图中。
这意味着“新增一个行业字段”和“关联一组合同记录”是不同层级的配置：前者改变数据描述，后者建立跨模块业务关系。设计时应同步考虑新增、编辑、详情和列表页面，避免只完成录入却无法查询、导出或授权。
事件流：描述“用户当前操作如何响应”
事件流连接组件事件、条件判断、数据请求、赋值、校验和提示。例如选择客户后加载联系人，选择产品后带出基础价格，金额变化后重新计算，提交前校验必填信息。LogicFlow 让交互关系可视化，但事件节点仍需明确输入、输出、失败分支和重入行为。
网络失败不能悄悄吞掉，重复点击不能生成两份订单，前端计算结果不能作为最终金额依据。事件流提升页面表达能力，后端领域服务仍执行最终校验。
外部接口：让配置页面连接真实领域服务
页面配置最终要落到真实业务接口。外部配置将新建、列表、删除、修改、详情、导入、导出和审批等动作映射到 mesh-crm-biz 与 mesh-bpm-biz 的领域接口，并明确请求方式、数据格式、结果字段和报错字段。表单负责采集数据，接口负责执行规则，两者通过显式契约连接。
因此，低代码并不等于绕过后端直接操作数据库。客户新增仍进入 CRM 服务完成编码、查重、归属和权限校验；审批仍由流程服务启动实例。接口配置使页面可替换、可组合，但领域规则仍只有一个可信入口。
数据转化：在模块之间建立受控流转
数据转化用于描述对象跨阶段或跨应用流动后的目标形态。客户可以因长期未经营进入公海，也可以在教育业务中转化为学生。字段映射解决源对象与目标对象的结构差异，自动转化规则定义触发条件，自动分配规则决定转化后的负责人，同时可以选择是否删除来源数据。
转化不是复制整行数据。系统需要保留来源关系、校验目标必填字段、处理重复数据并记录操作轨迹。对于客户转学生这类跨域场景，CRM 继续保存客户经营关系，教育模块保存学员身份与教学过程，两者通过明确映射关联，而不是相互覆盖。
工作流：让跨角色协作留下可信轨迹
合同审批不是一个“已通过”字段。它包含申请人、当前节点、参与人、条件分支、处理意见、时间和最终结果。折扣超过阈值可进入经理审批，大额合同继续进入财务或法务；驳回后回到申请人修改，再次提交形成新的处理轨迹。
蝉鸣 CRM 的流程设计页面基于滴滴开源项目 LogicFlow 构建。LogicFlow 是专注流程可视化的前端解决方案，提供节点与连线编辑、撤销、对齐线和快捷键等开箱即用能力，同时支持自定义节点、扩展交互及 BPMN 数据转换，适合承载可定制的企业流程设计场景。
流程设计器将开始、普通节点、审批节点和结束节点放在可视化画布中，连线表达推进方向，右侧面板配置当前节点。图中审批节点采用“发起人自选”和串签方式，也可以继续配置高级规则、显示样式及子流程。设计人员由此能同时检查流程结构和节点参与规则，减少隐藏在代码条件中的审批歧义。
真实业务通常会在这条基础链路上增加条件分支：普通折扣由直属负责人审批，超过阈值进入财务复核，特殊合同进入法务节点。子流程适合复用统一的用印、付款或交付检查。无论画布如何调整，已运行实例的轨迹、节点意见和处理时间都应保留，新的流程版本只影响明确发布后的业务。
流程只负责“谁在何时处理”，领域服务负责“业务能否这样变化”。流程通过后更新合同状态时，服务仍需检查合同是否已作废、金额是否变化、当前操作者是否具有接口权限。这样即使未来换流程设计器，业务规则也不会消失。
一个需求如何组合四层能力
以“旅游定制方案折扣审批”为例：自定义表单记录目的地、人数和资源偏好；事件流根据产品与人数生成报价预览；工作流处理超权限折扣；合同服务校验最终金额和客户归属。四层协作比把所有逻辑塞进一张表单更容易维护，也比每个行业复制一套系统更可持续。
上线前应检查：配置是否有版本和发布范围，事件流是否覆盖失败路径，工作流是否能找到正确参与人，领域接口是否校验租户与数据范围，历史实例是否受新配置影响。低代码缩短的是表达和交付距离，而不是测试与治理责任。
什么时候不该使用低代码
高并发核心交易、复杂算法、强一致库存、跨系统长事务和高度敏感操作不适合只靠页面配置。它们需要清晰代码、自动测试、性能评估和审计。反过来，字段差异、轻量台账、页面联动和审批路径正是低代码高收益区域。