A synchronous plug-in on the case table retrieves the related customer account to read two columns, accountnumber and creditonhold, and profiling shows the retrieval is a large share of the save time. The code currently calls Retrieve with new ColumnSet(true). What change best improves performance without changing the logic?
Select an answer to reveal the explanation.
Short Explanation
Asking for every column when you need two is like ordering the whole menu to eat a side salad. Name the two columns you need and the retrieval gets lighter right away. The trap is changing the delivery method while leaving the order exactly as big as it was.
Full Explanation
Retrieving all columns forces Dataverse to read and return every attribute of the account, including large text and lookup columns that may require joins, even though the logic uses only two. Specifying a ColumnSet with accountnumber and creditonhold reduces the work done in the database, the payload and the time spent inside the synchronous transaction, which is why Microsoft guidance and the solution checker flag retrieving all columns as a performance issue. The logic is unchanged because the same two values are read. A FetchXML query with the all-attributes element is the FetchXML equivalent of retrieving every column, so it carries the same cost, and Dataverse does not cache query results for plug-ins on that basis. ExecuteMultiple is a batch message discouraged inside plug-ins, and wrapping a single all-columns retrieval in a batch keeps the same query cost while adding overhead. Moving the retrieval to an asynchronous step cannot feed values back to the synchronous step through shared variables, because the asynchronous step runs later in a separate execution; the synchronous logic would no longer have the data when it needs it. Exam caveat: the same rule applies to RetrieveMultiple queries and to Web API calls, where $select limits columns. Operational check: compare the trace log durations for the step before and after the change under the same load.