权限与工作流配置避雷：Twenty 二次开发的高频翻车点

最近这段时间，开源 CRM 圈子里最火的选手非 Twenty 莫属。

GitHub 上五万多颗星，口号喊得很直接——做 Salesforce 的开源替代品，而且是为 AI 时代重新设计的。国内外不少技术博主都在实测，今日头条上“月费砍到零”“Salesforce 坐不住了”之类的标题一个接一个。

于是很多公司动了心思：反正免费、能自己部署，不如拉一套下来，改成自家的客户管理系统。

结果真正动手之后，翻车现场一个比一个精彩。

有人说：“我工作流明明配好了，它就是不触发。” 有人说：“我改了个权限，第二天销售说客户数据全没了。” 还有人说：“我就导了个 CSV，结果给三千个客户群发了邮件。”

这些问题，几乎都不是 Twenty 的 bug，而是它的“设计逻辑”和你脑子里的直觉不一样。今天咱们不讲代码，只讲人话，把二次开发里最容易踩的几个坑一次说清楚。

一、先搞明白：Twenty 到底是个什么东西

你可以把它想成一套用乐高积木搭起来的客户管理系统。

传统 CRM 像买现成的精装房，户型是固定的，你想把客厅改成书房，得砸墙、得加钱、得等厂商排期。

Twenty 更像给你一整箱积木：客户、公司、商机这些“标准件”它给你了，剩下的“合同”“供应商”“售后工单”你可以自己拼。拼好之后还能配一套自动化流水线——比如新客户进来自动分配销售、商机停滞三天自动提醒。

更关键的是，这一切配置都能像文档一样存进 Git，团队里谁改了什么一清二楚，不满意随时回滚。这也是它被开发者追捧的核心原因。

但“自由”这东西，永远是把双刃剑。积木能搭城堡，也能搭出一碰就塌的危楼。

二、翻车点一：对象建模，建的时候爽，改的时候哭

很多人第一次进后台，看到“数据模型”四个字就兴奋了，唰唰唰建了十几个自定义对象，字段一口气加了几十个。

然后发现不对劲。

第一个坑：字段类型一旦建好，就改不了了。

你建了个“合同金额”字段，选成了文本类型，想着先跑起来再说。等你想改成数字好做统计的时候，系统告诉你：不行。

这就像水泥浇筑，浇下去那一刻就定型了。官方的建议是：新建一个正确类型的字段，把老数据迁过去，再把旧字段停用。麻烦，但没别的路。

第二个坑：自定义字段其实做不了“必填”。

是的，你没看错。目前 Twenty 的自定义字段都允许为空，系统层面不会拦你。想要“不填就不许保存”，只能靠工作流去检查、去提醒、去拦截。

第三个坑：删掉的字段也算数。

一个对象最多能放 1600 个字段，而且这个数字包含已经删除的字段。有人折腾了半年，反复增删测试，突然发现加不了新字段了——因为额度被“历史遗迹”占满了。

第四个坑：标准对象删不掉，只能“停用”。

客户、公司、商机这些原生对象，你只能把它藏起来，数据还在。而且它们的 API 名称是写死的，改不了，只能改显示名称。

还有人会问：多对多关系怎么建？目前的答案是——先建一个“中间对象”，两头各挂一个一对多。比如“人员和项目”的多对多，就造一个“项目分配”对象来当红娘。

这些都不是致命错误，但每一条都能让你在项目中期多花两三天。建模型之前先在纸上画一遍，比在后台点十遍有用得多。

三、翻车点二：权限，最容易“看起来没事”的雷区

权限这块，是二次开发里最容易出事故的地方，因为它出问题时往往悄无声息。

坑一：以为权限是“加法”，其实是“套娃”。

Twenty 的权限是层层继承的：先设“所有对象”的基线权限，再针对某个对象单独覆盖，最后还能细化到某个字段。

听起来很合理，但实际配置时，很多人只改了全局那一层，以为所有人都能看了，结果某个对象上还留着历史设置的“不可见”。用户登录进来，数据是空的，第一反应就是“系统把我的数据弄丢了”。

真相是：数据一直在，只是被一层你没注意到的设置挡住了。

坑二：“删除”和“彻底删除”是两回事。

普通删除是软删除，还能恢复；只有“销毁”才是真删。给销售开通删除权限的时候，最好想清楚：你是想让他能清理无效线索，还是想让他能把公司资产一键蒸发？

坑三：一个人只能有一个角色。

这是硬规则。你要是想要“既能看到财务字段，又能管理团队成员”的组合权限，不能叠加两个角色，只能新建一个专门的角色，把权限一项项勾出来。

坑四：删角色会“集体降级”。

删掉某个角色后，原本属于这个角色的成员会被自动重新分配到默认角色。如果默认角色权限给得比较宽，那就等于一夜之间给一批人悄悄提了权。

坑五：只能看不能改，怎么设？

给字段勾上“可见”但不勾“可编辑”，就是只读。这个用法很实用，比如让全员看到“客户等级”，但只有主管能改。

坑六：按行授权要花钱。

“销售只能看自己的商机”这种行级权限，属于高阶套餐功能。免费版或自托管版如果没开，别在方案里写得太满，最后交付时容易尴尬。

一句话总结：配完权限，一定要拿一个普通员工的账号真登录进去看一眼。 管理员视角永远是“一切正常”的。

四、翻车点三：工作流，看着跑起来了，其实全错

工作流是 Twenty 最诱人的功能，也是翻车率最高的地方。

最经典的坑：手动新建记录，工作流拿到一堆空字段。

很多人用“记录被创建”作为触发器，测试时在界面上新建一条客户，结果自动发出的邮件里，客户名是空的、金额是空的。

为什么？因为 Twenty 是实时自动保存的，没有“编辑完再点保存”这个动作。你敲下第一个字，记录就已经创建了，工作流立刻开跑——那时候你后面十几个字段还没填呢。

官方的解法很朴素：手动录入场景，改用“记录被创建或更新”这个触发器。等用户填完保存，数据齐了再跑。

如果你只想让它跑一次，可以加个判断，比如检查“创建时间和更新时间是否相同”，或者干脆加个“已处理”的勾选字段。

第二个坑：分支默认是并行的。

你画了个如果…否则…的流程，以为只会走一条路。实际上两条分支会同时执行。想要互斥，得在每条分支开头加一个过滤条件，条件不满足的那条自动停。

不夸张地说，这个设计让不少人给同一个客户发了两封内容矛盾的邮件。

第三个坑：忘了激活。

草稿状态的工作流，配得再漂亮也不会跑。这个错误听起来很蠢，但它是官方故障排查文档里的第一条。

第四个坑：触发字段没勾。

选了“记录被更新”，却忘了指定监控哪个字段，结果改个备注都能触发一遍，一天跑几千次，额度哗哗掉。

第五个坑：搜索记录最多返回 200 条。

想批量处理五百个客户？搜索结果只给你两百个，剩下的悄无声息地没了。要么加过滤条件分批跑，要么改用定时任务。

第六个坑：速率限制是硬墙。

每分钟 100 次是软限制，超了排队慢慢跑；每小时 5000 次是硬限制，超了直接判失败，而且失败记录可能压根不出现在列表里，你会以为工作流“消失了”。

第七个坑：失败不会自动重试。

目前没有自动重试机制。挂了就是挂了，你得自己看运行记录、自己修、自己手动再跑一遍。所以关键流程里，最好加几个前置检查节点，别让脏数据一路冲到底。

第八个坑：导入 CSV 前没关工作流。

这是杀伤力最大的一条。你导入五千条客户，每条都触发一次“新客户欢迎邮件”，结果就是五千封邮件飞向真实客户。官方明确建议：大批量导入前，先把相关对象的工作流停掉，导完再开。

第九个坑：定时任务按 UTC 走。

你以为设的是早上九点，实际跑起来是下午五点。做日报、做提醒的，务必换算时区。

第十个坑：代码动作有超时。

默认五分钟，最长十五分钟。跑重活、做大计算，很容易卡死在这里。

五、那普通人还能不能玩？门槛到底高不高

能玩，而且分三档。

第一档，纯小白。 直接注册官方云版，什么都不用装，浏览器打开就能建对象、拉视图、配工作流。适合想先看看这东西长什么样的老板和小团队。

第二档，有点技术底子的。 用 Docker 在自己服务器上拉起来，数据完全自己攥着。适合对数据合规敏感、又不想每年交大笔订阅费的公司。

第三档，开发者。 官方提供了脚手架工具，一行命令生成项目骨架，把对象、字段、权限、工作流全部写成可版本管理的配置，改完一键发布。这也是 Twenty 最有意思的地方——它把 CRM 变成了一个可以像软件一样迭代的工程资产，而不是一个越用越乱的后台。

但要提醒一句：第三档的坑，就是前面讲的那些。它的自由度高，意味着它不会像传统商业软件那样，用一堆弹窗把你拦在错误操作前面。

六、写在最后

Twenty 之所以火，不只是因为“免费”两个字。

真正打动人的，是它把 CRM 从“买一个黑盒子”变成了“自己造一个透明盒子”。数据在哪、权限怎么走、自动化什么时候触发，全都看得见、改得动、存得下。

但自由从来都带成本。对象建错要重建，权限配错会“数据消失”，工作流配错会给客户群发邮件——这些翻车故事，本质上都是在为“没有约束的自由”买单。

所以给准备动手的朋友一句实在话：先花半天把数据模型画在纸上，再用一个测试账号把权限跑一遍，最后拿三条假数据把工作流从头到尾试一次。这三步做完，能砍掉八成的返工。

最后想问问大家：你们公司在换 CRM 的时候，最舍不得的到底是哪个功能？是那些年积累的客户标签，还是那套只有老员工才懂的自动化流程？评论区聊聊，说不定你的踩坑经历，正好能救下一个正准备上线的同行。