A custom API recalculates the credit limit of exactly one account each time it runs, and callers always know which account they are targeting. The developer wants the Web API call to address that account directly and wants the plug-in to receive it without defining an extra parameter. Which binding should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
Think of binding as addressing an envelope: Entity binding writes one specific account's address right on the front. The platform even hands your plug-in that address as Target, so you don't define it yourself. Watch the trap: a function can't change data, so it's the wrong pick for a recalculation that saves.
Full Explanation
Binding is an OData concept that ties an operation to a table. When a custom API uses Entity binding, Dataverse automatically creates a request parameter named Target of type EntityReference and passes it to plug-ins registered for the message, and Web API callers invoke the operation on the record itself by appending the fully qualified name to the row's URL. That matches an operation that always acts on one known account. EntityCollection binding associates the operation with the table's entity set; it does not add any parameter that identifies particular rows, so the plug-in would have no account to work on. A Global API with no parameters has no bound row, so there is no primary entity for the plug-in to read and the caller would have no way to say which account to recalculate. Setting Is Function makes the operation an HTTP GET that returns data without making changes, which conflicts with saving a new credit limit. Exam caveat: Microsoft notes that a Global API with an explicit EntityReference parameter can achieve the same result, so binding is a design convenience rather than the only option; the stem's wish to avoid defining a parameter is what selects Entity binding. Operational check: inspect the $metadata document and confirm the action is bound to account and lists the Target parameter.