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 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 a 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 SDK for .NET.

• 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.
  • Custom process actions can be used in client-side JavaScript in model-driven apps by using the Xrm.WebApi.online.execute method.
• With the SDK for .NET, 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 Power Platform CLI pac modelbuilder build command.
  • More information:
    • Generate early-bound classes for the SDK for .NET
    • Use messages with the SDK for .NET

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 PreValidation, PreOperation and 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.

Tip

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's activated. You can't 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 establishes a dependency in the solution that prevents deleting the Custom Process Action.

Required permissions

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 privilege 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 absence of restriction isn't an advantage. The workflow can't 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 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.

The existing Depth platform checks ensure an infinite loop doesn't occur. For more information on depth limits, see MaxDepth.

Tip

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.

See also

Create a custom process action
Use actions
Classic Dataverse workflows