How to Integrate Microsoft Dynamics 365 with V0

The foundation of Dynamics 365 API access is an Azure AD app registration. Go to portal.azure.com, navigate to Azure Active Directory → App registrations → New registration. Give the app a name (like 'V0 Dynamics Connector'), leave the redirect URI blank for a server-to-server integration, and click Register. After registration, you will see the Application (client) ID — this becomes your DYNAMICS_CLIENT_ID environment variable. Note also the Directory (tenant) ID — this is your DYNAMICS_TENANT_ID. Next, go to Certificates & secrets → Client secrets → New client secret. Give it a description and set an expiration (12 or 24 months). After clicking Add, copy the secret Value immediately — you can never see it again after leaving this page. This becomes DYNAMICS_CLIENT_SECRET. Now grant the app access to Dynamics 365. Go to API permissions → Add a permission → APIs my organization uses → search for 'Dynamics CRM' → select Application permissions → check user_impersonation. Click Grant admin consent for your tenant. Finally, you must add the app as a Dynamics 365 application user inside Dynamics 365 itself. In Dynamics 365, go to Settings → Security → Users → switch the view to Application Users → New. Set the Application ID to your Azure app's client ID, give it an appropriate security role (like Sales Person or System Customizer), and save. Without this step, your app will authenticate with Azure but be denied access by Dynamics 365.

With the Azure setup complete, prompt V0 to generate the front-end interface for your Dynamics 365 integration. Enterprise CRM dashboards typically include summary metrics, tabular data with sorting and filtering, and detail views for individual records. For a sales pipeline view, describe the layout V0 should generate: a summary bar at the top with total pipeline value and deal count, a Kanban board or table showing opportunities, and filter controls for date range, sales rep, and deal stage. For an account management view, describe the two-panel layout: a searchable list of accounts on the left and a detail panel on the right that shows related contacts, open cases, and recent activities when an account is selected. For a lead creation form, describe the fields and validation: all fields that your Dynamics 365 Lead entity requires, dropdown options that match your Dynamics 365 option sets, and error handling for required field validation. V0 handles enterprise table designs well. Ask for features like column sorting, pagination controls, row click navigation, and sticky headers for long lists. Specify that the data should be fetched from your Next.js API routes (not directly from Dynamics 365) — V0 should generate standard fetch calls to /api/dynamics/* endpoints.

Create a token helper and your main Dynamics 365 API routes. The token helper fetches an OAuth2 Bearer token from Azure AD using the client credentials flow — this token is then included in every Dynamics 365 API request as an Authorization header. The token endpoint format is https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token. You post a URL-encoded form body with grant_type=client_credentials, your client_id, client_secret, and scope (https://{DYNAMICS_INSTANCE}.crm.dynamics.com/.default). Cache the access token in memory between requests since it is valid for 3600 seconds. This avoids unnecessary token requests on every API call. A simple module-level cache with an expiry timestamp works well for Vercel serverless functions, though note that each function instance has its own cache — very high traffic may still make multiple token requests. Your Dynamics 365 API routes query the Web API using OData syntax. The base URL is https://{DYNAMICS_INSTANCE}.crm.dynamics.com/api/data/v9.2/. Common entities: accounts for company records, opportunities for deals, leads for inbound leads, incidents for support cases, contacts for individual people. OData select ($select) limits which fields are returned, filter ($filter) applies WHERE conditions, expand ($expand) includes related entities, orderby ($orderby) sorts, and top ($top) limits results. All these go in the URL query string. Example: /accounts?$select=name,revenue,ownerid&$filter=statecode eq 0&$orderby=revenue desc&$top=50.

1// lib/dynamics-auth.ts
2interface TokenCache {
3  token: string;
4  expiresAt: number;
5}
6
7let tokenCache: TokenCache | null = null;
8
9export async function getDynamicsToken(): Promise<string> {
10  if (tokenCache && Date.now() < tokenCache.expiresAt - 60000) {
11    return tokenCache.token;
12  }
13
14  const tenantId = process.env.DYNAMICS_TENANT_ID!;
15  const scope = `https://${process.env.DYNAMICS_INSTANCE}.crm.dynamics.com/.default`;
16
17  const params = new URLSearchParams({
18    grant_type: 'client_credentials',
19    client_id: process.env.DYNAMICS_CLIENT_ID!,
20    client_secret: process.env.DYNAMICS_CLIENT_SECRET!,
21    scope,
22  });
23
24  const response = await fetch(
25    `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,
26    {
27      method: 'POST',
28      headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
29      body: params.toString(),
30    }
31  );
32
33  if (!response.ok) {
34    throw new Error('Failed to obtain Azure AD token');
35  }
36
37  const data = await response.json();
38  tokenCache = {
39    token: data.access_token,
40    expiresAt: Date.now() + data.expires_in * 1000,
41  };
42
43  return tokenCache.token;
44}
45
46// app/api/dynamics/accounts/route.ts
47import { NextResponse } from 'next/server';
48import { getDynamicsToken } from '@/lib/dynamics-auth';
49
50export async function GET() {
51  try {
52    const token = await getDynamicsToken();
53    const baseUrl = `https://${process.env.DYNAMICS_INSTANCE}.crm.dynamics.com/api/data/v9.2`;
54
55    const response = await fetch(
56      `${baseUrl}/accounts?$select=name,revenue,numberofemployees,ownerid&$filter=statecode eq 0&$orderby=revenue desc&$top=50`,
57      {
58        headers: {
59          Authorization: `Bearer ${token}`,
60          'OData-MaxVersion': '4.0',
61          'OData-Version': '4.0',
62          Accept: 'application/json',
63        },
64      }
65    );
66
67    if (!response.ok) {
68      return NextResponse.json({ error: 'Dynamics 365 query failed' }, { status: response.status });
69    }
70
71    const data = await response.json();
72    return NextResponse.json(data.value);
73  } catch (error) {
74    return NextResponse.json({ error: 'Internal server error' }, { status: 500 });
75  }
76}

Go to Vercel Dashboard → your project → Settings → Environment Variables. Add the following server-side variables — none should have the NEXT_PUBLIC_ prefix as they are all sensitive credentials. DYNAMICS_TENANT_ID: Your Azure Active Directory tenant ID. Found in Azure portal → Azure Active Directory → Overview → Tenant ID. DYNAMICS_CLIENT_ID: The Application (client) ID of your Azure AD app registration. Found in Azure portal → App registrations → your app → Overview. DYNAMICS_CLIENT_SECRET: The client secret value you copied immediately after creating it. If you did not save it, go to Azure portal → App registrations → Certificates & secrets → delete the old secret and create a new one. DYNAMICS_INSTANCE: Just the subdomain part of your Dynamics 365 URL. If your Dynamics 365 instance is at https://mycompany.crm.dynamics.com, the value is mycompany. For different Dynamics 365 regions, the suffix may be .crm4.dynamics.com or .crm.microsoftdynamics.de for government clouds — use the full domain if non-standard. After saving all variables, push a commit to trigger a new Vercel deployment. Test the integration by navigating to your deployed app and verifying that the dashboard loads with real Dynamics 365 data. Check Vercel Function Logs for any authentication errors.