Importing metadata from Dynamics 365

Dynamics 365 metadata comes into your catalog straight from your environment: no export file to prepare, no local agent to pair, no schema to hand model. Connect once, discover, choose what matters, and DeltaVault builds the tables, columns, and relationships for you.

Before you start

• No local agent needed. DeltaVault connects to your Dynamics 365 environment directly, unlike a database source that discovers metadata through a paired local agent.
• Someone registers the application first. Before you can create the connection, a person with Microsoft Entra administrator rights in your tenant registers an application and grants it access to the environment. An application registration on its own cannot read your metadata: it also needs an application user inside the environment, holding a role that can read entity definitions.
• Need the walkthrough? Registering the application, creating a client secret, creating the application user, and assigning the minimum security role all happen in your Microsoft Entra tenant and your Dynamics 365 environment, before you create the connection here. If this has not been done yet, ask your DeltaVault contact or your organization’s administrator to walk you through it.

Create the connection

Create a new connection and choose Dynamics 365 as the source type, then fill in:

• Environment URL. Your environment’s address, for example https://yourorg.crm.dynamics.com.
• Tenant ID and Client ID. The Microsoft Entra application registration’s identifiers.
• Client secret. The application’s client secret. DeltaVault stores it encrypted and never shows it again after you save: to rotate it later, paste the new value in and save.

Verify the connection

Click Verify. DeltaVault runs a real probe against your environment: it requests a token from Microsoft Entra, then calls the environment to confirm the token actually works there. A connection reads Verified only once both of those succeed.

A failed verify falls into one of four classes:

• Wrong credentials. The tenant, client, or client secret does not check out with Microsoft Entra. Compare all three against the application registration.
• Application user not granted access. Entra accepted the credentials, but the environment rejected the request. The application registration exists but has not been added as an application user in the environment, or that application user has no security role that can read metadata. Revisit the application user setup step.
• Service protection limits. The environment is throttling requests. Wait, then click Verify again.
• Environment URL or connectivity problems. The Environment URL does not resolve to a working Dynamics 365 environment, DeltaVault could not reach Microsoft Entra or your environment over the network, or something else went wrong completing the request. Double check the Environment URL against your environment’s actual address, and retry: a transient network problem often clears up on its own. If it persists, contact your DeltaVault contact or administrator.

Discover entities

1. Open the workspace where you want to import. Its Details tab carries the Import metadata action; you will also find it on the workspace Catalog page, and on a project’s Details and Workspaces tabs.
2. Click Import metadata.
3. In the Import metadata dialog, choose Cloud discovery. This option is available once the connection is verified.
4. Click Next.

DeltaVault lists every entity in your environment and reports them under a single group named after the connection: Dynamics 365 has no schema layer to group entities under, the way a database does.

Choose what to import

• The default view shows business entities: the tables that hold your actual customer, sales, and operational data.
• Turn on Show all entities to also reveal system tables, including workflow logs and the join tables behind many to many relationships. Leave it off unless you specifically need one of those.
• Use the search box to jump straight to an entity by name instead of scrolling the tree.

What gets imported

For every entity you select, DeltaVault imports:

• The table itself, and its columns, with each column’s type translated into your catalog’s data types.
• Column lengths and decimal precision, carried over from the source definition.
• The primary key.
• Column descriptions.

Five attribute types never make it into the catalog. File and Image are handles to large objects rather than values. Virtual, PartyList and CalendarRules are non-scalar system attributes. None of the five maps onto a catalog column, so DeltaVault skips them rather than importing something misleading.

How relationships are imported

• A lookup pointing at exactly one entity becomes a foreign key. DeltaVault carries the relationship straight into your catalog.
• Lookups pointing at the user table are skipped. Every record carries created by and modified by lookups, and importing them would add noise rather than meaning.
• A lookup that can point at several different entity kinds is imported as a plain column with no foreign key. There is no single correct target, so DeltaVault leaves the choice to you rather than guessing.
• A lookup pointing at an entity you have not imported yet is kept, and it connects on its own. The next time you import that entity from the same Dynamics 365 connection, the foreign key completes itself. Import your entities in whatever order suits you.

Troubleshooting

If some entities are missing after an import, check the review screen: it lists the entities DeltaVault could not read, so you know exactly what to retry instead of guessing why your table count looks short.