A developer has built a plug-in class that must run synchronously in PostOperation when an account is updated, with access to the account's previous name. Using the Plug-in Registration Tool against a Dataverse environment, in what order should the developer register the components?
Select an answer to reveal the explanation.
Short Explanation
Think of it like building your house: foundation, then walls, then windows. The assembly is the foundation, the step hangs on a plug-in type from that assembly, and the image hangs on the step. The trap is trying to attach an image to the assembly or the type; images belong to steps.
Full Explanation
In the Plug-in Registration Tool, the assembly is registered first, which uploads it and creates plug-in type records for each class that implements IPlugin. A step is then registered against a plug-in type, specifying the message, primary table, stage, execution mode and any filtering attributes; here that is Update of account in PostOperation, synchronous. Finally, an image is registered on that step, defining whether it is a pre-image or post-image, its entity alias and its columns, such as name for the previous account name. Each component depends on the one before it, so the order is fixed. A step cannot be registered before its assembly, because the step must reference a plug-in type that only exists once the assembly is registered, and images are never attached to assemblies. An image cannot be registered for a table independently of a step; images are defined per step so that Dataverse knows when to capture them. Plug-in types have no image registrations; the image belongs to the step because different steps on the same type can need different snapshots. Exam caveat: after registration, add the assembly and steps to a solution so they move between environments through ALM. Operational check: in the tool's tree view, confirm the hierarchy shows assembly, plug-in type, step and image, then update an account name and verify the trace.