Implement Microsoft Power Platform
Where Power Platform carries Customer Service
Almost every Customer Service customization is a Power Platform artifact. The apps themselves - Customer Service Hub, Customer Service workspace, and the Omnichannel app - are model-driven apps delivered in a solution. Forms, views, charts, dashboards, and the command bar are configured in the app designer. Business rules enforce field-level logic (show or hide, set values, validation) at form or entity scope; they run client-side and cannot create records or call external services.
Power Automate handles the asynchronous side: record creation and update rules that convert emails or social posts into cases are flows, SLA warning and failure actions are workflows, and unified routing uses flows behind the scenes. Business process flows guide agents through stages. Solutions carry everything between environments, and the managed versus unmanaged distinction matters for deployment. Copilot Studio bots plug into Omnichannel as a channel.
Traps: business rules have a scope - form scope does not run server-side, so validations that must always apply need entity scope or a plug-in. Classic workflows still appear as SLA actions even though new automation should be built as flows. And a flow owned by a departing maker's connection will fail.
Rule of thumb: if the requirement says 'immediately, on the form', use a business rule or JavaScript; if it says 'when a record is created, do something elsewhere', use a cloud flow. Worked example: auto-numbering a case reference on save belongs in a synchronous flow or plug-in, not a business rule.