Kav Desk for Dynamics

Onboarding Kav Desk for Dynamics: the 13-step wizard

The only wizard in the whole Studio — 13 steps across four services, from Entra directory binding to a published side panel inside Dynamics 365.

By The Kav team Published 4 min read

Kav Desk for Dynamics is a side panel that opens inside Microsoft Dynamics 365, so an agent who lives in the CRM all day can take a Kav conversation without leaving the record they're already working. Getting there is the one genuinely multi-step process in the whole Studio — nowhere else does a screen make you go through a sequence, because nowhere else needs one. This wizard touches four separate backend services (Tenancy, Bridge, Registry, Connectors) in order, and it will not let you skip ahead of what's actually been done.

Before you start

Kav registers one multi-tenant Entra application for every customer — you never register your own. Have ready: your Dynamics environment's Entra directory (tenant) ID, its environment URL, and a Power Platform admin who can grant consent and create an application user.

The 13 steps

  1. Bind the directory. Enter the customer's Entra directory ID, choose the assurance level this binding grants staff who sign in through it, and optionally list JIT (just-in-time) group GUIDs — leave this empty and every staff member needs an individual link instead (see the separate guide on maintaining a live surface).
  2. Admin consent. The wizard builds a real Microsoft admin-consent URL against Kav's own platform Entra app id — send it to the customer's admin. Once they consent, paste a test ID token from a real sign-in here; the token is decoded client-side only (no signature check — this is a diagnostic, not the real validation) purely to confirm its tid matches what you entered in step 1.

Steps 3 and 4 are the customer's own actions, outside the Studio entirely — the wizard only records that they happened.

  1. Import the managed solution. The customer's own Dynamics admin imports Kav's managed solution into the target environment. Confirm it with the checkbox once it's done.
  2. Create the application user. In the Power Platform admin center, the customer creates an application user for Kav's Entra app and assigns it Kav's built-in security role. Confirm with the checkbox.
  3. Register the environment. Give the surface a slug, the environment URL, the environment's own GUID, and the directory tenant ID (checked against step 1's binding), and choose where the panel docks — a side pane or a productivity pane. This step is also where you add the origins allowed to embed the panel at all; a surface can't activate later with zero origins.
  4. Test the connection. A live checklist — consent granted, solution installed, application user exists, role assigned — some rows return "unknown" until a live Dataverse probe is wired up, which is why this step still ends in a manual "I verified this externally" confirmation rather than an automated pass. 7–8. Allowlist tables and actions, and set the ceiling. One screen, two concerns: which connector instance this surface calls through, which Dataverse tables and connector actions it may touch (e.g. kav_conversation, row-create), and — right beside it — the maximum data-sensitivity class it may write (Public through SpecialCategory) and a daily request budget.
  5. Check the metadata. A live schema-drift check isn't wired up yet either, so this step is a manual confirmation that the target table and columns actually match what your mapping expects.
  6. Build the field mapping. The real editor: each target Dataverse column gets a mapping expression built from a closed, eight-node vocabulary — a constant, a source path, a vendor lookup by alternate key, an option-set translation, a concatenation, a truncation, a date format, or a language-templated string. This compiles to the same Scriban expression language every other capability's request template already uses.
  7. Scope who can use it. Grant a predicate — can open the panel, can be impersonated, can own created records, can run setup — to a directory group, a vendor role, or a vendor team. Add as many grants as the rollout needs before continuing.
  8. Simulate. A pure, local interpreter runs your mapping against sample data with no live Dataverse call at all. A lookup-by-alternate-key node reports honestly as unresolved here, since simulating a live vendor call isn't something a browser can do.
  9. Publish. Pin the solution version you imported in step 3 and activate. This is the one irreversible-feeling step in the wizard — the panel goes live the moment you confirm.

The wizard remembers a surface you registered in an earlier session: retype the same slug at step 5 and it resumes there instead of trying to register it twice.