Logic Composer

Logic recipes

Run validations, logic flows and business processes automatically when records of a table are created, updated or deleted.

A logic recipe binds your logic to the life cycle of one Dataverse table. When a record of that table is created, updated or deleted, the recipe checks it with validation blocks and runs logic flows or business processes before and after the change is saved. Use a recipe instead of writing plug-ins: the rules stay visible in one place, and you change them in the designer.

Before you begin

The table must already exist in Dataverse.
The recipe’s project must belong to an unmanaged solution. Otherwise saving fails with “Cannot create logic recipe because the solution … associated with the project … is a managed solution.”
The validation blocks, logic flows and business processes you want to run should already exist. You can add them to the recipe later too.

Create a recipe

Go to Logic FabricLogicLogic Recipes and select New.
Enter a Name and choose the Project.
In the editor, answer Which table does this recipe react to? by searching the Table box (for example account) and choosing a table. This fills in Entity on the form and opens the editor.
On the Create, Update and Delete cards, add validations and actions to the stages you need (see below).
Save the form.

Name, Project and Entity are locked after the first save. To point logic at another table, create a new recipe.

The recipe editor

Each event (Create, Update and Delete) is a card. The card header says when it runs (“Runs when a record is created”, and so on) and counts what each stage holds, for example “Validation 1 · Before 0 · After 2”. You can collapse a card to its header.

Inside each card, three numbered stages run in order:

#	Stage	What the editor says	What you can add
1	Validation	“Logic blocks that can stop the operation”	Validation and Validation set logic blocks only
2	Before Create / Before Update / Before Delete	“Runs in the same transaction, before the change is saved”	Logic flows and business processes. Always synchronous: there is no Async switch.
3	After Create / After Update / After Delete	“Runs after the change is saved, right away or in the background”	Logic flows and business processes, each with an Async switch

An empty stage reads “No validations yet.” or “No actions yet.” Each item appears as a compact row with a chip for its kind (Logic block, Logic flow or Business process), its project, and a Background chip when it runs asynchronously. Hover over or focus a row to Edit, View, Open, Move up, Move down or Remove it. The order within a stage is the order the items run in.

Select Expand to let the editor fill the whole browser window; it then shows “Runs on” followed by the table name. Select Collapse or press Esc to return. Expand appears once a table is chosen.

Add a validation

In the Validation stage, select Add validation.
Choose the Validation Logic Block. Only Validation and Validation set blocks are offered.
Map each of the block’s Inputs to an expression, usually a column of the record.
Optionally enter an Applies When: condition (see below).
Select Save.

Add an action

In the Before or After stage, select Add action.
Choose the Action Type: Flow or Business Process.
Choose the logic flow or business process, and map its Input values.
In the After stage, set Async to Yes to run the item in the background, or No to run it right away.
Optionally enter an Applies When: condition.
Select Save.

Choose the columns the logic can use

Create: Select Properties chooses which columns of the new record are available to the logic.
Update: Entity Updated Properties chooses the columns whose change triggers the recipe and whose new values are available. Entity Before Update Properties chooses the columns whose previous values are available, so you can compare old and new. Only the columns changed in that save carry values: a selected column that was not part of the update is empty, not its current value. Read the record if you need its other current values.
Delete: only the ID of the record being deleted is available, to validations as well as flows. To use other columns, pass the ID to a flow in Before Delete and read the record there with Get Entity By Id; by After Delete the record is gone.

Pick only the columns you need. On Update, choosing a narrow set of triggering columns keeps the recipe from running on unrelated edits.

Run an item only in some cases

Every validation and action has an optional Applies When: condition. It must be a Yes/No expression. The item runs only when the condition is Yes; when you leave it empty, the item always runs. For example, apply a discount check only when Status Reason is Submitted, or notify finance only when the estimated revenue is above 100,000.

How validation messages reach users

When a validation in the Validation stage fails, the operation is cancelled and the user sees an error:

Block kind	Message the user sees
Validation	The name of the logic block
Validation set	The names of the rules that failed, one per line

Name your validation blocks and rules as the sentence you want users to read, for example Credit limit cannot be negative or Close date must be in the future. With a validation set, the Return First Validation Error toggle decides whether users see only the first failed rule or every failed rule. See Validation set.

A logic flow in a Before or synchronous After stage that ends with Raise Error also cancels the operation; the user sees ERROR_CODE: Error message (only the code when the flow sets no message). In an asynchronous After stage the user sees nothing: the background job fails and shows the message.

When a flow in these stages fails unexpectedly, for example because a save is refused, the user sees the full technical error text. To give users a readable message, check for the problems you can foresee in the flow and end it with Raise Error and a clear code and message.

Turn a recipe off

Set Disabled to Yes on the recipe form to stop it from reacting without deleting it. Set it back to No to turn it on again. From a deployment pipeline you can also use the CLI commands disable-recipe and enable-recipe; see the command reference. The CLI commands switch the recipe on or off directly and do not change the Disabled field, so after using them the form may not show the recipe’s real state; the next save that changes Disabled applies the field’s value again. They also work where the project’s solution is managed and the recipe form is read-only.

How it behaves

Validation runs first. If any validation fails, the create, update or delete is cancelled and nothing in the later stages runs for that operation.
Before items run in the same transaction as the change, before it is saved. If one fails or ends with Raise Error, the save is cancelled and all changes are rolled back.
After items run once the change is saved. With Async set to No they run right away; with Yes they run in the background, so the user does not wait for them. A failing synchronous After item also cancels the save; a failing asynchronous one does not.
A table can have several recipes. When more than one reacts to the same event and stage, the order between recipes is not defined; within one recipe, items run in list order.
Recipes track the configuration values and localized resources their logic uses, so those cannot be deleted while a recipe still uses them.
If part of a saved recipe cannot be read, the editor still opens with what it could read and explains the problem (“Parts of this recipe couldn’t be read, so they are left empty.”). When whole stages had to be left out, saving is turned off so they are not lost.
Recipes in a project whose solution is managed open read-only.

Example: guard and enrich opportunities

A sales team wants opportunities to be checked when they are created and updated, and finance to be notified about large deals.

Create a recipe on the Opportunity table.
On the Create and Update cards, add the validation set Opportunity rules to the Validation stage. Its rules are named Estimated revenue must be positive and Estimated close date must be in the future, so users see exactly those sentences when a rule fails.
On the Create card, add the flow Create qualification tasks to After Create with Async set to No, so the sales rep’s follow-up tasks exist as soon as the opportunity is saved.
On the Update card, select estimatedvalue under Entity Updated Properties and under Entity Before Update Properties. Add the flow Notify finance of large deal to After Update with Async set to Yes and Applies When: estimatedvalue > 100000.

Users get immediate feedback from the validations, every new opportunity gets its tasks, and the notification runs in the background without slowing down the save.