这才是 PaaS 平台应有的能力！

本文着重探讨伙伴云 aPaaS 平台的高级特性，这些特性是伙伴云真正的亮点，也是它在 PaaS 平台中的竞争力所在。这些特性使伙伴云能够成为一个高效、稳定和可靠的 aPaaS 平台，并为用户提供完善的企业级应用解决方案。

之前我们拆解了伙伴云的在线协作表格，看起来非常像飞书的多维表格。但是，光看伙伴云的在线协作表格并没有太多特别的亮点，毕竟之前见过了纷享销客的 PaaS 和飞书的多维表格。看来，只有伙伴云的高级特性才能够挖掘它真正的aPaaS实力了。

本篇，我们来探索伙伴云的 aPaaS 平台的高级特性。

一、权限管理

伙伴云的权限可以针对各类业务对象设置，这不仅包括了数据表格，还包括了触发器、业务流程等等。以数据表格为例，可以通过数据表格的更多操作入口进入到权限设置界面。

针对普通成员（邀请协作的成员，默认的权限组），可以有多种控制权限的方法。比如设置管理所有数据、只能管理自己的数据或自定义权限。

其中自定义权限和我们之前讲过的纷享销客的业务对象权限控制是类似的，也是从三个维度进行权限控制。

1）数据操作权限

包括查看、创建、修改、删除、分享、锁定、导出、选择全部成员、单字段修改和批量编辑等操作。

2）字段操作权限

字段的查看、创建和修改权限。实际上这就是控制数据的列权限。

3）数据范围权限

可以通过某些字段条件限制用户访问的数据范围，例如可以限制访问的问题分类，或者只能查看处理人自己的数据。

可以自定义权限组，类似于我们的角色，然后给权限组分配数据操作、字段管理和数据范围权限。

伙伴云默认一个成员只能属于一个权限组，但是升级到企业版之后，允许保留某个成员在其他权限组的权限，也就是一个成员可以有多个权限组。

一个比较好的权限控制设计是当权限配置发生了改变，会要求刷新界面，避免权限变更后还缓存旧的权限，导致越权查看数据或操作数据。

二、触发器

如果接触过数据库知识的话，就应该对触发器不陌生。

触发器是在满足一定的条件，比如新增数据、修改数据、删除数据、数据的日期字段到期等等，然后再设定触发执行任务的具体条件，比如某某字段发生了变更，再执行相应的工作流操作，从而实现业务自动化。

这里我们建立了一个触发器，当某条数据的处理人发生变更时（处理人新值不等于旧值），给新的处理人发送一条通知，告诉新的处理人有待处理的问题反馈。

通知的内容支持自定义，内容中可以插入当前数据的指定字段，例如这里我们插入的提醒内容中包括了修改人字段。

我操作修改了一条数据的处理人后，就收到了系统的通知（App端也同时收到了）。这种场景对于任务分配来说还是挺实用的。

注意：这里如果想发消息给触发人自己（比如我自己修改了一条数据，想通知自己），伙伴云这块默认是不发送提醒的，因为毕竟给自己刚刚修改的操作行为发提醒是没必要的。

但是，如果要发给自己，可以将发送人设置为工作流，这个时候是可以向自己发送消息的。

除了发送消息之外，触发器还可以执行一些其他操作，比如创建新数据、修改已有数据、锁定/解锁数据、调用外部接口（需要升级版本）等等。

一个典型的应用场景就是，比如我一个客户，在客户档案填写时填写一个联系人和联系方式，就可以直接创建一条客户联系人数据。

三、数据校验

数据校验可以对数据表的字段进行校验，从而保证数据格式正确填写，减少人为录入错误。

这个和我们的产品中的表单校验是相同的，只是这里的校验规则需要我们自己编写。这里我们设置了一个手机号的校验规则。

我们要求手机号长度必须是11位，且前两位是13/14/15/16/17/18/19开头。

数据验证失败的时候可以设置错误提示文案。

配置好之后就可以对手机号字段进行校验了。

四、操作向导

操作向导是在完成某个数据操作后可以引导用户进行其他相关的操作，这些操作包括：

• 创建数据。比如完成客户档案填写后，引导填写客户联系人数据；创建数据时可以根据当前数据填充默认数据，简化填写过程，比如添加联系人时自动填充客户信息。
• 修改指定数据。跳到目标数据表，修改满足条件的数据。
• 查看数据。查看某一条数据的详情。
• 查看应用。查看某个数据表（伙伴云的一个数据表就是一个应用）。
• 查看仪表盘。查看某个仪表盘。
• 访问指定URL。比如引导用户填写完后关注服务号（跳到一个带二维码的网页），访问URL支持携带参数，因此如果我们有自定义的前端应用，可以携带一些参数访问与当前数据关联的前端网页。

这里我们设置了两个向导：一个是跳到网页，一个是创建数据。

我们添加一条数据后，会弹出下面的操作引导。

五、流程

流程分为审批流和工作流，之前我们拆解分销逍客的时候由于版本问题没有体验到工作流，而伙伴云这块对免费账号是开放相应能力的，使得我们有机会看看它的工作流是怎么设计的。

1. 审批流

审批流程和我们之前讲过的钉钉OA审批流程差不多。不同的是，伙伴云的审批没有自定义表单，而是需要绑定数据表格，相当于是按照数据表格的表单发起审批。审批发起的入口也是在绑定的数据表格的某一条数据的详情页面。

当然，单独发起也是可以的，这样就需要填写数据表格对应的表单。

审批流不提供流程图设计功能，而是直接设置不同的分支流程。好处是可以明确各个分支的走向，缺点是没法将共同的分支节点合并为一个节点。

审批发起后会在数据详情中显示相应的流程。

配置流程后会在数据表格中展示相应流程的基本信息，这些流程可以作为触发器的触发条件，比如流程审批通过后锁定数据不让编辑。

流程同样支持权限设置，设置的方式和之前的权限管理相同，这里就不再重复了。

2. 工作流

工作流是为协同处理一项工作设定的流程，有助于将一项工作流程标准化，每个角色各司其职，确保工作按设定流程进行，形成SOP。

举个例子：我们的一个售后问题，会有客服录入问题、相关业务部门受理问题安排处理人、处理人解决售后问题。这个流程就可以固化为“录入->受理->解决”这样一个工作流程。与审批流不同，审批流除了发起环节，其他审批环节基本只需要填写审批意见，工作流则可以在每个环节填写表单，以确保每个环节填写相应的数据。

伙伴云流程中心支持国际BPMN2.0标准，包括2种启动事件、5种工作节点、3种网关、2种结束事件。一个流程最多可以容纳500个节点，能够满足用户自由、灵活地搭建贴合业务的系统流程。

工作流采用类似流程图的方式绘制，需要包括启动方式（即流程入口，包括人工启动、定时启动两种方式），工作节点，流程分支（通过网关实现）和结束方式（自然结束和强制结束）。

这里我搭建了一个简单的工作流程，包括了录入问题、受理问题和解决问题。其中解决问题有意设置了两个并行任务（现实中存在多部门共同完成一项任务，比如我们产品研发的前端和后端开发）。

伙伴云同时支持线上任务和线下任务，线上任务需要确认办理、支持填写表单，而线下任务则只是给出提醒。

工作流节点支持4项设置：

1）节点信息

节点名称、节点任务说明、是否支持查看前续流程和后续流程。

2）执行人

指定节点的执行人，多人情况下支持单例模式（类似抢单，一人执行后即完成），顺序多例（依次分发任务，需要全部任务人依次完成），并行多例（同时分发任务，需要全部任务人完成）。

执行人支持从多组设定条件中选择，可选人员范围包括流程发起人、工作区（团队成员）、流程变量或数据表数据中的人员中选择。

3）数据操作

定义当前节点的数据操作行为，包括查看数据、修改数据和创建时间。同时可以设置查看和操作的字段，例如录入环节可以限制不录入处理人、解决时间。

同时，可以自定义数据校验规则（有些数据可能在表格不需要录入，但是到工作某个环节是必须填写的）。如果是查看或修改数据，支持对候选数据表的数据进行排序，因为流程会选择排序最靠前的数据供当前环节处理。

下面是流程自定义的校验规则，这条规则将数据表格的受理人字段修改成了必须和当前操作人一致，因此没有填写或填错时会提示错误信息。

4）操作按钮

定义节点的操作按钮。在流程提醒中会默认有个办理按钮，点击后会出现设定的系统按钮，可以自定义该按钮的名字。

同时还支持设定办理按钮，办理按钮分为三类，保存数据并完成、同意并完成和不同意并完成。其中后两个可以设置是否需要填写完成意见。

工作流设置好之后，可以保存发布，然后就可以到工作区的流程中发起流程了。发起流程就会根据设定的流程图一个个节点往下走，直至完成。

下面是我们按设定的流程出现的步骤，当工作流转到下一个环节时，系统会给出相应的待办提醒。

并行网关后的节点会同时发送多个任务到相应的执行人。其中我这边设置了一个线下节点一个线上节点，线下节点只需要查看详情（无需办理，App端需要确认收到）。

六、打印模板

打印模板采用类似 Word 的方式编辑，内容中可以插入数据表的字段和管理的数据表，选中内容后会弹出样式编辑工具栏，从而调节样式，因此可以非常灵活地设计自己所需要的打印模板。

打印模板支持使用已有数据进行预览，可以提前查看打印效果。这种打印模板设计非常灵活也易于操作。

模板同样支持设置权限，只是权限设置比较简单，即按用户组设置是否允许某个用户组使用当前的打印模板。

七、总结

如果说上一篇我们拆解的伙伴云在线协作表格是优秀的评价的话，那么这一篇我们看到的高级特性才是真的惊艳。

如果只是停留在自定义字段填报数据的功能上，充其量就是另一个版本的“多维表格”。但是，伙伴云的触发器、操作向导、流程则让我们具备了使用伙伴云搭建完整业务系统的能力。

除此之外，伙伴云还具备了仪表盘、数据仓库的能力，使得伙伴云具备了从基础信息化、业务流程化到数据资产化的能力。

如果说，有兴趣做 PaaS 平台或为 SaaS 平台客户提供自定义配置能力的产品经理，伙伴云的设计值得你们仔细研究一番。

​Read More