A developer is writing one plug-in class registered on Create, Update and Delete of a table. How does the plug-in get the record being processed from IPluginExecutionContext for each of these messages?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: A developer is writing one plug-in class registered on Create, Update and Delete of a table. How does the plug-in get the record being processed from IPluginExecutionContext for each of these messages? Correct Answer: From InputParameters["Target"], which is an Entity for Create and Update and an EntityReference for Delete Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/microsoft/ab-400/AB-400-e1-q147.webp)
Short Explanation
Target is always the parcel the request carries, but the shape of the parcel depends on the message. Create and Update deliver a full Entity, while Delete delivers just an EntityReference. If you cast it to Entity on Delete, you'll get an invalid cast exception.
Full Explanation
For Create and Update, InputParameters contains Target as an Entity holding the columns sent in the request; for Update, that means only changed columns plus the ID. For Delete, Target is an EntityReference, which identifies the row by logical name and ID but carries no column values. A plug-in shared across these messages therefore checks the type or message name before casting, for example testing whether Target is an Entity or an EntityReference. Reading PrimaryEntityId and retrieving the row adds a request for data the request already carries, and it rests on the false idea that Target exists only on Create; on Delete the row may also be gone by the time a later stage retrieves it. Entity images are not populated automatically; they must be registered on the step with a name chosen by the developer, and pre-images do not exist for Create while post-images do not exist for Delete. OutputParameters carry the message response, such as the new ID for Create; they do not hold Target for these messages. Exam caveat: on Update, columns not changed in the request are absent from Target, so logic needing the full row should register a pre-image or post-image with the required columns. Operational check: write a branch for each type, register the class on all three messages, and confirm trace logs show the expected Target type for each.