Processes

Process actions let callers run business operations, not just read and write fields. Each process action calls a Dataverse action (for example “Approve quote”, “Escalate case” or “Recalculate pricing”) with the inputs the caller sends, and returns the action’s outputs. Use them when the operation has rules of its own that should run in Dataverse, rather than rebuilding those rules in the app.

Two kinds of process action

Kind	Where you add it	Runs	Address
Entity process action	An entity’s Process actions	On one record of that entity	POST /{module}/{entity}/{action}?id={recordId}
Module process action	The module’s process actions	On its own, not bound to a record	POST /{module}/{action}

For an entity process action, the caller passes the record’s id on the query string as id; it is required.

Which actions you can expose

The list offers the Dataverse actions in your environment (“Add Process Actions From Dynamics”). That includes logic blocks and logic flows you made available in Dataverse with Expose as Dataverse Action (on-premises: Expose as Action), so you can put Logic Fabric logic behind an API endpoint without extra work. See AI and API exposure.

Add a process action

1. Open the entity (for an entity process action) or the module (for a module process action) and select Add process action.
2. In Definition, enter the Action Name and pick the Dynamics Process Action Name, the Dataverse action to call.
3. In Input, define the arguments callers send.
4. Map them under Process Input Argument: for each input of the Dataverse action, choose the API input, fetched value or expression that feeds it.
5. Under Process Output Argument, choose which outputs of the Dataverse action are returned to the caller, and under which names.
6. Add Data Fetcher queries if the precondition needs data, then set Access Control.
7. Save with Ctrl+S.

How it behaves

• Process actions are POST requests with a JSON body that holds the inputs.
• On success the caller gets 200 OK and a JSON object with the outputs you mapped, or an empty object when there are none.
• If the Dataverse action itself fails (for example, a business rule in it rejects the request), the caller gets 400 Bad Request with the error code and message that the action reported.
• The usual checks run first: input validation, data fetchers, the authorization policy and the precondition. See Access control.
• Everything the Dataverse action does, such as creating records, starting flows or sending email, happens as it would if someone ran it in Dataverse.

Example: approve a quote from a sales app

A field-sales app lets managers approve quotes. A logic flow, exposed as the Dataverse action crm_ApproveQuote, checks the discount against the manager’s limit, sets the quote’s status and returns the approved total.

Step	Setting
Definition	Entity process action approve on quote in module Sales; Dynamics Process Action Name crm_ApproveQuote
Input	comment (String, optional)
Process Input Argument	Comment ← input comment (the action runs on the quote identified by id)
Process Output Argument	ApprovedTotal → approvedTotal
Access Control	Demand User Role SalesManager

POST /sales/quote/approve?id=9d4c2b1a-7e6f-4a3b-9c8d-1e2f3a4b5c6d
Authorization: Bearer eyJ0eXAiOi...
Content-Type: application/json

{ "comment": "Approved — strategic account, 12% discount agreed with finance." }

{ "approvedTotal": 48720.00 }

Related

• Actions
• Access control
• Responses and errors