Dataverse 数据模型
数据表、关系和业务规则的设计要能同时服务多个应用或流程,而不是在每个组件中重复搭建。
当一个项目不再是单一应用,而变成微软低代码工具集中的多个部分协同运作时,迪拜企业往往会考虑迪拜聘请 Power Platform 开发工程师:面向一线员工的画布应用、在员工提交后触发响应的 Power Automate 流程,以及底层同时为面向公众的 Power Pages 网站提供数据的 Dataverse 数据表。根据 Microsoft 官方指导文档,Power Platform 是微软对这一整套工具集的统称,涵盖 Power Apps、Power Automate、Power Pages、Copilot Studio 以及它们共同依托的 Dataverse 平台,而 Power Platform 开发工程师正是能够在这些部分之间自如切换,而非只专精其中一项的通才型角色。
本页专门介绍这一通才角色。如果您的项目明确且完全属于其中一个组件,我们的 Power Apps 开发工程师、Power Automate 开发工程师 和 Power BI 开发工程师 页面分别更精确地匹配更聚焦的需求,也更便于据此评估候选人。
Power Platform 开发工程师负责构建的内容
跨越工具集中多个部分的交付成果。
数据表、关系和业务规则的设计要能同时服务多个应用或流程,而不是在每个组件中重复搭建。
读写这一共享 Dataverse 基础的画布或模型驱动应用,在模型变化时保持一致。
对 Dataverse 中的变化作出响应的 Power Automate 云端流程,将更新推送到另一个应用、一封邮件或一个外部系统。
读写同一 Dataverse 平台的外部网站,用于客户门户或公开表单。
让 Power Platform 能与其原生不支持的系统通信的连接器,以及用于标准控件无法实现的界面的 PCF 组件。
解决方案结构、环境策略和管道,让不断增长的应用、流程和网站集合保持可管理,而不是变成一堆各自为政的临时搭建。
值得关注的技能
在整个工具集上具备广度,并在其中某个领域拥有真正的深度。
| 技能或工具 | 合格的表现 | 为何重要 |
|---|---|---|
| Dataverse 建模 | 设计数据表和关系时能服务多个组件,而不是只为单一应用孤立设计 | 只为单一应用搭建的模型,一旦第二个应用需要用到它,拆解成本会很高 |
| Power Fx 与低代码逻辑 | 编写简洁、可测试的 Power Fx,而不是别人无法理解的深层嵌套公式 | 难以阅读的低代码同样是技术债,即便没有编译器 |
| 扩展点的把握 | 清楚何时该使用插件、自定义连接器或 Power Apps 组件框架,何时低代码工具已经足够 | 过早诉诸代码会增加平台本不需要的维护成本 |
| 治理与 ALM | 对解决方案和环境进行结构化管理,让不断增长的应用集合保持可控 | 一旦多个团队同时在其上构建,缺乏治理的 Power Platform 环境很快就会失控蔓延 |
| 安全模型意识 | 理解 Dataverse 安全角色如何影响基于同一数据表构建的每个应用和流程 | 一个共享数据表中的安全漏洞会影响读取该表的每一个组件 |
Microsoft 官方的 Power Platform 指导文档 将治理和环境策略列为平台的核心内容,而非事后补充,这一点值得核实候选人是否真正读过,而不只是看过入门制作工具的教程。
合作方式
如果是一项界定清晰的跨组件工作,例如一个数据模型、一个应用以及连接两者的流程,通常属于有明确完成节点的限定范围项目。如果 Power Platform 环境持续增长,经常需要新增应用和流程,则更适合由专属开发工程师每月在您的团队内部持续工作。如果目标是打造您自己长期的 Power Platform 内部能力,招聘支持服务适合这种情况,我们会作为其中一环负责技术评估。如果尚不确定某项需求是否真的适合用 Power Platform 实现,还是用其他方式会更合适,咨询服务能在您投入预算之前,帮助您判断这项工作是否真的适合用 Power Platform 来完成。
候选人评估
揭示真实跨组件经验的考察方式,而不只是某一项工具用得熟练。
而不是单独的某一个应用。在迪拜评估候选人时,可以问数据模型、应用和自动化流程是如何衔接的,以及他们现在会重新调整哪些部分。
询问他们在真实项目中是如何搭建环境和解决方案结构的,以及当两个人同时想修改同一内容时发生了什么。
优秀的候选人能举出一个确实需要插件或自定义连接器的具体需求,并解释为什么单靠低代码不够用。
一个涉及数据表、一个简单应用和一个流程的简短场景,重点考察各部分之间的协同设计,而不只是每个部分能否单独运行。
每一位在共享 Dataverse 模型上工作过的开发工程师都遇到过这种情况。他们如何发现并修复问题,比一份工具清单更能说明问题。
认证
目前有一项认证覆盖这一通才角色,且正处于过渡阶段。
根据 Microsoft 官方认证页面,该认证对应的考试正从 PL-400 过渡到 AB-400,AB-400 的报名已经开放,PL-400 的报名将于 2026 年 10 月 16 日截止。两者最终都指向同一项 Associate 级别认证,涵盖跨工具集的自定义开发、集成和 AI 驱动逻辑。
一个可供审阅的跨组件项目,以及候选人能清楚说明何时选择代码而非配置,这些比证书本身更能说明其日常的判断力。在因为这项认证而聘用候选人之前,建议索取 Microsoft Learn 的成绩单链接,而不是一张徽章图片。
阿联酋相关事项
两个在迪拜真实 Power Platform 项目中经常出现的方面。
当多个应用和一个面向公众的 Power Pages 网站都读取同一 Dataverse 数据表时,2021 年第 45 号联邦法令,即阿联酋的联邦数据保护法,适用于该共享数据的安全保护方式,因此应在搭建第一个应用之前就与开发工程师讨论访问权限设计,而不是等到之后。
当应用或 Power Pages 网站面向讲阿拉伯语的员工或客户时,表单、标签和验证信息从一开始就应按从右到左的方式构建和测试,这一点值得在开发开始之前与迪拜的 Power Platform 开发工程师确认。
如果需求明确是单一应用,请参见我们的 Power Apps 开发工程师 页面;如果只涉及自动化,请参见 Power Automate 开发工程师。基于这些数据的报表工作由我们的 Power BI 开发工程师 页面负责。如果工作实际上属于 Dynamics 365 自身的应用范畴,请参见 Dynamics 365 CRM 开发工程师 或 Microsoft Dynamics 365 开发工程师。完整分类位于 迪拜聘请开发工程师 下的 Microsoft 与 Dynamics 365。
直接解答
Power Apps 开发工程师专注于应用本身,包括画布应用和模型驱动应用。Power Platform 开发工程师则涉及更广泛的工具集,包括应用、流程、Power Pages 以及底层的 Dataverse 平台,适合工作内容不局限于单一产品的项目。
如果您的需求明确只是一个应用,我们的 Power Apps 开发工程师页面与之更匹配,也更便于评估候选人。如果工作同时涉及一个应用、一个自动化流程和一个面向公众的 Power Pages 网站,本页更适合。
不是,不过两者共用同一底层数据平台 Dataverse。Dynamics 365 的应用,例如 Sales 和 Customer Service,都建立在 Power Platform 之上,但 Power Platform 开发工程师这一角色范围更广,涵盖与 Dynamics 365 本身无关的自定义应用和自动化工作。
在日常工作层面通常可以,因为 Power BI 与其共用同一 Microsoft 数据生态。如果职位主要是报表、数据模型和仪表盘,我们的 Power BI 开发工程师页面更贴近需求。
两者都需要。大多数工作使用 Power Fx 和低代码构建工具完成,但 Power Platform 开发工程师也会经常通过 Power Apps 组件框架、插件,以及用 C# 或 TypeScript 编写的自定义连接器来扩展平台功能,以满足低代码工具无法覆盖的需求。
列出涉及的每一个组件,应用、流程、Power Pages 网站或 Dataverse 数据表,以及应该做出哪些改动。一次简短的通话即可补充其余信息,随后您会收到一份针对该简报量身定制的书面固定价格方案。
资料来源
书面固定价格
已收到,我们正在为您撰写报价。
工作时间内您将在 45 分钟内收到。请查收确认邮件。