A code app shows a grid of Dataverse invoice rows. When a user selects a row and clicks Recalculate, the app must run a bound custom action named cr5a2_RecalculateInvoice on that row. How should the developer wire this up?
Select an answer to reveal the explanation.
Short Explanation
Think of a bound action as a button that lives on one specific row; you have to tell it which row you mean. The CLI generates a typed service for the action, and the row ID goes in as the first argument. Faking it with a flag column and a plug-in doesn't run the action at all.
Full Explanation
Code apps call Dataverse actions and functions through generated services. The developer uses pa app find-dataverse-api to locate the operation, then pa app add dataverse-api with its name. The CLI reads the operation from the Dataverse metadata document, writes its schema, updates power.config.json, and generates a service class named for the operation. For a bound operation, the generated method takes the ID of the row it operates on as its first argument, followed by the declared parameters, so passing the selected invoice ID runs the action on that row. Updating a flag column that a plug-in watches is a workaround that does not invoke the custom action, duplicates its logic elsewhere, and fires unrelated update steps. The generated table service's get method retrieves a row; select lists columns and has no ability to invoke operations. Routing through a cloud flow adds latency and a dependency when the code app can call Dataverse actions directly. Exam caveat: if the action's definition changes, rerunning pa app add dataverse-api with the same name regenerates the schema and service. Operational check: open the generated service, confirm the first parameter is the bound row ID, and test the action against a sample invoice.