A developer is registering a synchronous PreOperation step on the Update message of the account table. The plug-in recalculates a risk score and must run only when the creditlimit column changes, not when a user edits the phone number, address or any other column. How should the step be configured?
Select an answer to reveal the explanation.
Short Explanation
Filtering attributes are the bouncer at the door: if creditlimit isn't on the guest list for this update, the plug-in never even wakes up. You get the behavior for free, with zero lines of code. The trap is thinking an image or configuration string can decide whether a step fires; they only hand data to code that's already running.
Full Explanation
Filtering attributes are a property of an Update step registration. When they are set, Dataverse evaluates the incoming request and invokes the step only if at least one listed column is present in the update payload. Setting creditlimit as the only filtering attribute therefore keeps the risk calculation from running when phone, address or other columns are edited, and it removes the execution cost entirely rather than exiting early inside code. A pre-image only supplies the row's values before the operation to a plug-in that is already executing; it has no effect on whether the step is triggered, so the plug-in would still run on every update. Execution order sequences multiple steps registered on the same message and stage; it controls ordering, not whether a step runs for a given column change. Secure configuration passes a string to the plug-in constructor; code could read it and exit early, but the step would still be invoked on every update, which is the cost the requirement is trying to avoid. Exam caveat: some clients send unchanged columns in an update, so filtering attributes reduce executions but the code should still compare values when the distinction matters. Operational check: update only the phone number and confirm in the plug-in trace log that no execution was recorded.