Custom Actions

In the previous step, you looked at building a workflow where you learned about conditional actions to create branches of actions, modification actions to update information, record values using static or dynamic values, and other additional actions. Now you are going to apply this knowledge to custom actions.

Custom Actions are a type of process very similar to real-time workflows. They have similar properties, created and edited in the workflow editor, and use the same building blocks: stages, conditions, and actions.

Unlike workflow processes, you don’t need to set the following options:

• Start When: Actions start when invoked by another process via Perform Action or when developer code calls the message generated for them.
• Scope: Actions always run in the context of the calling user.
• Run in the background: Actions are always real-time workflows.

Actions also have something that workflow processes don’t – input and output arguments.

Use actions to create a new operation that is not available in Common Data Service or Dynamics 365 for Customer Engagement apps or to combine multiple disparate operations into a single operation. For example, in the case of a support call center, you could combine Create, Assign, and SetState operations into a single new “Escalate” operation.

Why Use Actions

When you create a custom action, you extend the functionality of Power Platform by creating a custom message. By combining multiple steps and logic, actions open a range of possibilities for composing business logic that is accessible as a new single message in Common Data Service.

Actions are like custom workflow activities in the sense that they encapsulate functionality. Custom workflow activities are blocks of functionality created and maintained by developers to be used by non-developers as part of the workflows. Actions are blocks of functionality that usually are implemented and maintained by non-developers declaratively like using standard workflow steps. More complex custom actions can still also have the logic implemented by developers.

Unlike workflows, actions cannot be triggered by an event, they need to be invoked. You can call actions declaratively from workflows using Perform Action step or business process flows using an Action Step. Developers can use the action message like any of the other messages provided by the platform.

When to Use Actions

Actions provide the ability to define a single message that matches an operation you need to perform for your business. These new messages are driven by a process or behaviour rather than what can be done with an entity. These messages can correspond to verbs like Escalate, Convert, Schedule, Route, or Approve – whatever you need. The addition of these verbs helps provide a richer vocabulary for you to fluently define your business processes. You can apply this richer vocabulary from clients or integrations rather than having to write the action within clients. This also makes it easier because you can manage and log the success or failure of the entire action as a single unit.

Creating an Action

Create action as you would with any other process: open an unmanaged solution that the action will be part of, use New > Process command, and select Action category. With actions processes, you can select an entity to provide context for the workflow just like other types of processes, but you also have the option to choose None (global). Use this if your action doesn’t require the context of a specific entity.

When you name the action, it’s important to choose an appropriate process name. When an action is saved, based on that name a unique message name including customization prefix is generated. This is the name of the message that a developer will use in their code. Don’t change this unique name if the process has been activated and code is in place expecting to call the action using this name.

There are some unique properties specific to actions:

Enable rollback: Generally, processes that support transactions will “undo” (or rollback) the entire operation if any part of them fails. There are some exceptions to this and with actions, you have the option to opt-out of this. You should consult with the developer who will use this message to determine whether it must be in a transaction or not. You can enable rollback if action is triggered by a developer’s code using Common Data Service message, the option does not apply if a custom action is invoked directly from within a workflow.

Define Process Arguments: In this area, you’ll specify any data that the action expects to start and what data will be passed out of the action upon completion.

After action properties are defined, add stages, conditions, and actions as you would when editing a real-time workflow. In addition to the steps that can be used for real-time workflows, actions also have the Assign Value step. In actions, these can be used only to set output arguments.

Using Actions

You can execute an action from workflows, as a business process flow action step or other process actions. Activated custom actions are available to processes by selecting the Perform Action item in the Add Step drop-down of the web application process form.

After the step is added to your process, you can select your new custom action (or any action) from the Action list provided in the step. Select Set Properties in the step to specify any input parameters that your custom action requires.

Note: Some parameter types, for example, Picklist, Entity, or Entity Collection, are not supported for active use in the workflows. If a custom action has any of these types, the custom action isn’t listed in the Action list.