多个部门共用低代码平台，权限、版本和交付怎么管？

刚开始用低代码，大家常问的是：业务部门能不能自己搭应用？

等采购、财务、人事都在上面做系统，问题就变了：这些应用，谁说了算？采购想给申请单加一个字段，财务的审批条件可能也要跟着改；人事调整了部门信息，其他应用还要不要继续按旧部门找审批人？

这不是低代码“不够简单”。恰恰是因为改起来快，更要说清楚谁有权改、改动从哪天生效，以及上线后由谁负责。不然一个部门省下的开发时间，可能变成另一个部门的核对时间。

“能用”和“能改”，别给成同一种权限

先看一个常见的误会：把采购部的人加进应用，给了“编辑”权限，就以为权限已经分好了。

可他要编辑的是什么？是自己提交的采购申请，还是整张申请表的字段？能改审批中的单据，还是能改审批规则？这几件事的影响完全不同。

拿一张采购申请单来说，采购员需要填写物料、数量和用途；部门负责人要审核；财务要看预算归属。财务可以核对预算，不代表能替采购修改申请数量。采购部负责这张单，也不代表任何采购员都能进入设计器，把“预算不足需财务审批”这条规则关掉。

所以，权限至少要分开看三层：谁能办理业务，谁能调整应用，谁能把调整发布给正式用户。办理业务时，还得继续问到数据范围：能看本人的、本部门的，还是所有公司的？敏感字段能不能看？

这不是为了把权限设得越细越好。设得太细、没人维护，人员一调岗就容易乱。更实用的办法，是先按岗位和责任配角色，再挑几张关键单据，用真实账号走一遍：这个人能不能看到不该看的数据？该他处理的申请会不会因为权限不足而卡住？

织信文档里，应用成员可以按用户、部门和角色授权；应用角色可以控制模块及数据操作，平台也支持更细的数据记录、字段和控件权限。它能提供分层配置的手段，但“采购经理该看哪些子公司的订单”这类边界，仍要企业自己定。尤其要记住，按钮看不见，不等于底层数据就没有访问权限；界面展示和数据授权都要核对。

版本不是留个“V2”名字就行

权限划好了，还会碰到下一件事：改动什么时候生效？

比如采购要新增“费用归属部门”。财务报表按这个字段汇总，审批流程也要按它找负责人。采购部门觉得表单改完就能用了，可财务的报表没改，已提交但尚未审批的申请也没说怎么处理。这时即便保存了一个V2版本，问题也还在。

版本管理要管的是改动的影响范围，不只是保留修改记录。准备上线前，把这次改动连着问清楚：新申请从哪天开始填？旧申请缺这个字段怎么办？报表按新旧哪种口径统计？正在流转的单据继续走旧审批，还是需要补填后再走新审批？

在织信，应用有版本管理和发布能力，工作流也支持多个版本及生效版本切换。不同环境部署时，官方文档还介绍了导出应用安装文件、在测试环境验证后再部署到生产环境的方式。这些能力能帮企业把“开发中”和“正式使用中”分开，但不能替业务部门决定旧单如何处理。

还有个容易被忽略的地方：回到旧版配置，不等于已经写入的数据也自动回到旧状态。如果一次发布改了字段、自动化或数据结构，上线前就要准备备份和恢复方案。织信的部署文档也明确建议，生产发布前备份数据库、共享存储和应用安装文件。别等出问题了才讨论“能不能回退”。

应用做出来，谁来接住后面的事？

低代码把做出初版这件事变快了，交付却不能只看页面能不能打开。

采购提出“加费用归属部门”，至少有几个人要把话说完整。采购说明什么业务必须填、谁来填；财务确认字段口径，以及报表和预算审批怎么用；负责搭建的人改表单和流程；应用管理员检查权限与关联应用，再安排发布。

上线后采购员发现填错归属，谁能改、改完会不会重新审批，也得有人回答。

这几件事不一定要由四个团队分别完成。小团队可以一人兼几项工作。关键是需求、验收、发布、运行维护各有明确负责人，不能默认“谁把应用搭出来，后面就全归谁”。

我会建议交付时只保留几样真正有用的东西：这次改了什么、影响哪些人和单据、用哪几笔业务验收、谁批准上线、上线后出问题找谁。让采购提交一张正常申请，再提交一张预算不足、需要财务审批的申请；看财务是否收到正确任务，看报表是否按新字段汇总。走不通，就回到具体环节改，而不是宣布“功能已交付”。

如果还有其他部门复用这张采购单，或另一个应用读取它的字段，验收人也不能只有采购部。织信支持应用之间访问经授权的数据表，也支持通过事件和API衔接应用。这让企业可以逐步搭建共享能力；同时也意味着，公共字段或接口一改，相关应用要一起检查。平台能提供连接应用的手段，谁来通知相关部门、谁来确认没有改坏，仍是交付责任。

不用先写一本厚厚的管理手册

多个部门刚开始共用平台，可以先挑一项会跨部门传递的改动，把完整过程走一遍。比如就用“采购申请新增费用归属部门”：先分清谁提需求、谁改应用、谁审核权限；在测试环境用新旧单据试一遍；确认财务报表和审批都接上了，再由有发布权限的人上线。

试完再看哪里卡住：是业务规则没人拍板，还是应用之间的依赖没人发现？是权限给得太宽，还是出了问题不知道该找谁？这些问题比先制定几十页规范更能告诉企业，下一步该补哪条规矩。

织信这样的企业级低代码平台，价值不只是让更多部门都能搭应用。它能把应用、数据、流程、权限和版本放在持续开发的底座上，让需求变化时有地方改，也有条件核对改动的影响。但共用平台不等于共用责任。谁能动正式环境、跨部门改动由谁验收、出了问题由谁接住，这三件事定下来，平台才有机会越用越顺。