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, build a proper bridge to the outside system, then land the data where the feature can actually see it on a regular schedule. That means describing the connection from the provider's OpenAPI specification and automating fresh job-change signals into a Dataverse table the analytics can read. Manual website checks, waiting for native support, or expecting the analytics engine to call an outside API live won't do the job.
Full Explanation
The correct approach is to build a custom connector from the provider's OpenAPI specification and use a scheduled Power Automate flow to write job-change signals into a Dataverse table that feeds relationship analytics. When the needed signal comes from a third-party system that exposes a documented REST API, extending relationship analytics with that signal requires bringing the data into Dataverse so the analytics feature can consume it. This gives relationship analytics a reliable, recurring source of job-change data without manual effort. Asking reps to check the provider's website manually before each account review and note job changes in the opportunity description field 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. Waiting until Microsoft adds native support for that specific data provider before attempting any integration is incorrect because it is passive and leaves the current business need unaddressed indefinitely, when a supported extensibility path already exists. Configuring relationship analytics' AI model settings to directly call the provider's REST API at inference time without any intermediate data storage 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.