A consultant wants relationship analytics for a strategic accounts team to factor in whether a contact has recently changed jobs, using data pulled from a third-party firmographic data provider that Dynamics 365 Sales does not natively integrate with. The provider offers a REST API with a documented OpenAPI specification. What is the most appropriate way to extend relationship analytics with this data?
Select an answer to reveal the explanation.
Short Explanation
When you need to feed outside data into an AI feature that only really understands what is sitting inside the CRM, the pattern is always the same: build a proper bridge to the outside system, then land the data where the feature can actually see it on a regular schedule. That is what turns a documented external API into something usable — describe the connection, then automate moving fresh data into a table the analytics can read. Having people manually check a website and jot down notes will not keep up and is not really extending anything. Sitting around waiting for a vendor to eventually build native support ignores that there is already a perfectly good way to do this yourself. And there is no setting that lets the analytics engine just reach out live to any outside API on its own — the data has to be brought in and stored first.
Full Explanation
The correct answer is A. When the needed signal comes from a third-party system that exposes a documented REST API, extending relationship analytics with that signal requires building a custom connector from the OpenAPI specification and using a scheduled Power Automate flow to land the data in a Dataverse table that the analytics feature can consume. This gives relationship analytics a reliable, recurring source of job-change data without manual effort. Option B is incorrect because manual, human-driven checking is unreliable, does not scale across a strategic accounts book, and is not an extension of the system at all, just an ad hoc workaround. Option C is incorrect because waiting for native support is passive and leaves the current business need unaddressed indefinitely, when a supported extensibility path already exists. Option D is incorrect because relationship analytics has no configuration for calling an arbitrary third-party REST API directly at inference time; the platform's supported extensibility pattern is bringing external data into Dataverse first, not live external calls from the AI model itself.