Use Custom Process Actions with code
Custom Process Actions, also known as simply Custom Actions, are one of two ways to create custom messages for the Microsoft Dataverse. The other is Custom APIs. More information: Create and use Custom APIs.
Both of these capabilities allow for creating new messages that can be called from web services. Custom Process Actions will continue to provide a no-code way to declaratively define synchronous business logic. Custom process actions have always been synchronous 'real-time' workflows and therefore not suitable to be converted to use Power Automate.
For a comparison of the capabilities of Custom Process Actions and Custom APIs, see Compare Custom Process Action and Custom API.
The business logic of a custom process action is implemented using a workflow. When you create an custom process action, the associated real-time workflow is automatically registered to execute in the main operation stage of the message execution pipeline.
For developers, the creation of a new message means you can use the message in code with either the Web API or the Organization service.
- With the Web API, the new messages created with Custom Process Actions are always OData actions. For information about calling actions using the Web API, see Use Web API actions.
- With the Organization service, the messages can be called generically in a late-bound style by using the OrganizationRequest class or by using early-bound request and response classes generated by the code generation tool (CrmSvcUtil.exe).
For information about creating a Custom Process Action using the workflow designer see: Create a custom process action
Extend Custom Process Actions
There are two ways to extend Custom Process Actions using code: with custom workflow activities or by registering plug-ins on stages.
Custom workflow activities
Because a Custom Process Action is a workflow, you can include re-usable custom workflow activities in the workflow definition as part of the workflow. More information: Workflow extensions
Register plug-ins steps for stages in the execution pipeline
Because a Custom Process Action creates a message, you can register plug-ins steps on the
PostOperation stages to modify the behavior of the Custom Process Action. Developers have used this to define all the logic for the message, frequently not defining any workflow logic at all. The Custom API feature simplifies this code-first pattern and provides other capabilities not possible with Custom Workflow Activities.
If you have been using Custom Process Actions solely to implement logic using plug-ins, consider moving to use Custom API instead. More information: Create and use Custom APIs
The message for a Custom Process Action is only available with the workflow that defines it is activated. You cannot register plug-in steps for a Custom Process Action that isn't active.
If you register any plug-in steps on a Custom Process Action it will establish a dependency in the solution that will prevent deleting the Custom Process Action.
A security privilege named Activate Real-time Processes (
prvActivateSynchronousWorkflow) is required to activate an action’s real-time workflow so that it can be executed. This is in addition to any privileges needed to create a workflow.
Watch out for long running actions
If one of the steps in the action’s real-time workflow is a custom workflow activity, that custom workflow activity is executed inside the isolated sandbox run-time environment and will be subject to the two minute timeout limit, similar to how plug-ins are managed. However, there are no specific restrictions on the amount of overall time the action itself can take. This is not an advantage. The workflow cannot run indefinitely. It will eventually fail for various reasons. For example, if an action participates in a transaction, where rollback is enabled, SQL Server timeouts will apply. Take care to ensure that your custom process actions can complete with a clear success or failure in a reasonable period of time. Anything longer than 2 minutes is probably too long.
A best practice recommendation is that long running operations should be executed outside of Dataverse using Power Automate, Logic Apps, or other capabilities offered by Azure.
Submit and view feedback for