新法至：若机缘之数逾五万，则标之待法审，并告交易之厅。凡久居Dataverse六载以上者，皆可置此理于四地。成熟之众半数之争，在择其宜处耳。
今示决树之理，并陈其于实境所显之费、迟、持之权衡。
四者之选
商道之则。明言式，于模型驱动之表运行于客户端。可设字段之值，显隐字段，定要件之级。不可呼他服务。
云中自动化流程，异步，服务器端运行。由数据表事件（创建、更新、删除）触发。可调用任何连接器——数据表本身、SharePoint、HTTP端点，诸如此类。可视化设计器。
旧式流程。Power Automate之遗制，存于Dataverse之内。尚存于若干模式（同步自定义动作，聚合字段重算）之支持，然微软之志在Power Automate。
插件（自定义代码）。C#之类别，注册于Dataverse执行之管。于服务器端运行，可同步（于原数据库交易之内）或异步。全.NET，全Dataverse SDK。
决策之树
各枝分岐处
商规之断，当其时：
- 需依API写入（此仅于模型驱动表单中发）
- 需于字段值中设条件逻辑逾AND/OR之限
- 需唤外部之务
其实，业务规则只适用于一种模式：'当字段A有值X时，显示/要求字段B'。任何更复杂的情况都会迅速变得难以阅读。
Power Automate在以下情况会失效：
- 你需要阻止验证失败时的保存（从Dataverse写入的角度看，Power Automate总是异步的）
- 你需要亚秒级延迟（新流程运行典型的冷启动延迟为3-10秒）
- 君处高流之境——流程运行，耗君每座或每流之许可
许可之困，实存。写触之插件，免费发火。同触之Power Automate流程，每事耗一运行。Dataverse表日见五十万写，在每流计划许可下（三月三流百金），无碍；在每用户计划许可下，必审其数。
插件崩坏之时：
- 非开发者亦需视之可配置以持之
- 尔自同步码中唤外HTTP端点（二时辰插件超时，兼HTTP迟缓，致失败）
- 尔欲使非技者，但观之，即知其用。
插件乃高量低延之策，适于Dataverse内部之逻辑。然若票单之“需求”栏乃商分析师周更之段，则非其宜。
新务勿用旧式流程。微软之文牍屡劝用Power Automate，吾等会其意。
例：机遇标识之需
归至"机缘之量逾五万，则举法理之察，并通知交易之案。"
析为二事：
- 举法理之察——设布尔之域acme_requires_legal_review为真。此乃行文之变，须于每度存（无论界面或API）而施，若他理倚此旗则阻存之进行。插件，同步，预行。以十行C#于名适之步中呈之。
- 通知交易台——发一封邮件或 Teams 消息。不急，时滞数小时无妨，需与 Outlook 或 Teams 连接器整合。Power Automate 云流程，触发于 acme_requires_legal_review = true 更新时。
二器一需。其分由“是否修改行”与“是否与非 Dataverse 整合”之问而定。
Teams 每择一器以应万变，终成二者：
- 四十步之Power Automate流程，能兼为之，时有所限，且当通知连接器不甚顺遂时，默然中断
- 一插件，以System.Net.Mail发信，遇Exchange Online认证辄败，且于代码中显露SMTP凭据
二器各有所长，相得益彰，胜于一器之竭力而用
吾辈合并之前所行之审察
每增逻辑之 pull request，审阅者必问四事：
- 此乃适器乎？（循上决策树而观之。）
- 若为插件，其置管道之阶当否？（预验与预行及后行——各具殊义。）
- 若为流程，其可幂等乎？（重试或生；流程复收顾客之费，实为患也。）
- 逻辑命名著录，使新进之员得寻之否？
问四为众队所略者。Dataverse予君四处置逻辑；若新至者不得见所择之一，必自增其五。