Dynamics integration

Kernel connects to Dynamics via secure OAuth, reading standard objects and writing only to Kernel fields with a minimal permission set.

What It Is

Kernel's Dynamics 365 integration lets Kernel read core CRM entities and write back Kernel-specific fields. The connection uses an Azure AD Application User with HMAC-SHA256 authenticated API calls, and access is scoped to an integration user with a minimal Security Role.

At a Glance

  • A Dynamics 365 admin installs the Kernel solution and opens the Kernel Setup custom page.

  • In that page, they create an Application User and Kernel automatically establishes the connection.

  • Kernel reads standard entities and only writes to Kernel-designated fields.


Data Fields

  • Kernel either (a) provides a specification of fields to add, or (b) includes them in the managed solution.

  • Kernel only writes to those Kernel fields; master data is not altered.

  • Fields are added as custom attributes to standard entities (Account, Contact, Lead, Opportunity).


What Gets Installed

Solution Components

  • Kernel Integration App with a Kernel Setup custom page

    • Create Integration User (one click, admin only)

    • Choose Existing User (select from dropdown)

    • Status panels showing sync state

    • User management (activate/deactivate)

  • Application User (Service Principal-based authentication)

    • No password required

    • Azure AD-backed identity

    • Follows principle of least privilege

  • Security Role (Kernel Integration Role)

    • Baseline read access to standard entities

    • Write access to Kernel-designated fields only

    • Execute permissions for custom actions

  • Plugins (C# assemblies)

    • KernelUserController - Manages integration user lifecycle

    • KernelPermissionReporter - Reports security role assignments

    • Registered on PostOperation pipeline stage

  • Custom Entities

    • krnl_kernelsyncstatus - Stores synchronization state

    • krnl_kernelsetting - Stores configuration settings

  • Custom Actions (Workflow processes)

    • User creation, deactivation, reactivation

    • Sync status management

    • Permission reporting

  • Custom Page (Power Apps component)

    • React-based UI for setup and management

    • Real-time status indicators

    • Loading animations with rotating messages


Data Access

Permissions Table

Object
Read
View-All
Edit

Account

✓ (All or select fields)

✓ (All or select fields)

✓ (Kernel fields)

Lead*

✓ (All or select fields)

✓ (All or select fields)

✓ (Kernel fields)

Contact

✓ (All or select fields)

✓ (All or select fields)

Opportunity

✓ (All or select fields)

✓ (All or select fields)

Task/Activity

✓ (All or select fields)

✓ (All or select fields)

SystemUser

✓ (Limited fields)

*Required only if you don't use Accounts.

Note: The integration user is not used for merge operations. Merging accounts requires elevated privileges. Users authorize merge actions directly in Kernel's UI when needed.

Field-Level Security

  • Read Access: Integration user can read all fields within assigned security role scope

  • Write Access: Limited exclusively to Kernel-prefixed fields (e.g., krnl_score, krnl_segment)

  • Field-Level Security: Respects Dynamics 365 field-level security settings

  • Business Unit Access: Scoped to integration user's business unit (or organization-wide if configured)


Security Model

Authentication

  • Method: Azure AD Application User with HMAC-SHA256 request signing

  • Credentials: Service principal-based (no password stored)

  • Request Signing: Each API request includes x-kernel-signature header with HMAC-SHA256 hash

  • Secret Key: Organization ID used as the HMAC secret

  • Token Management: Uses Dynamics 365 Web API authentication context

API Security

  • Transport: All API calls use HTTPS with 1.2 IIRC

  • Signature Verification: Server validates HMAC signature on every request

  • Timeout: API calls timeout after 2 minutes (configurable)

  • Retry Logic: Exponential backoff for transient failures (max 3 retries)

Access Control

  • Security Roles: Fine-grained control via Dynamics 365 security roles

  • Business Units: Respects business unit hierarchy and access

  • Field-Level Security: Honors all field-level security settings

  • IP Restrictions: Compatible with your organization's IP allowlist settings

  • Conditional Access: Supports Azure AD conditional access policies

Credential Storage

  • API Credentials: Stored in Kernel's secrets manager (AWS Secrets Manager / Azure Key Vault)

  • Organization ID: Used for HMAC signing, never exposed in logs

  • Audit Trail: All API access logged in Dynamics 365 Audit Summary View

Revocation

  • Deactivate User: Deactivate the integration user in Dynamics 365 Settings → Security → Users

  • Remove Security Role: Unassign the Kernel Integration Role to revoke specific permissions

  • Delete Solution: Uninstall the Kernel solution to remove all components

  • Portal Revocation: Click "Disconnect" in Kernel portal to stop sync immediately


FAQs

How does Kernel authenticate?

Through an Azure AD Application User with HMAC-SHA256 request signing. The application user is created during setup and linked to an Azure AD service principal. Each API request includes a cryptographic signature that Kernel's API validates using your organization ID as the secret key.

Who creates the Integration User?

A Dynamics 365 admin creates it directly inside the Kernel Setup custom page (one click). The system automatically:

  • Creates the application user

  • Assigns the Kernel Integration Role

  • Establishes the API connection

  • Sends initial sync notification

No separate Azure AD admin portal access is required for basic setup.

Can we restrict permissions?

Yes. You have several options:

  1. Modify Security Role: Edit the Kernel Integration Role in Settings → Security → Security Roles

  2. Custom Security Role: Assign your own custom security role instead of the default

  3. Field-Level Security: Use Dynamics 365 field-level security to restrict specific fields

  4. Business Unit Scope: Assign the integration user to a specific business unit

The Kernel portal also allows you to configure custom field mappings per customer.

How do we revoke access?

Multiple options:

  1. Deactivate User: Settings → Security → Users → Find Kernel Integration user → Deactivate

  2. Remove Security Role: Unassign the Kernel Integration Role from the user

  3. Portal Disconnect: Click "Disconnect" in Kernel portal Settings → Integrations

  4. Delete Solution: Settings → Solutions → Delete "Kernel Dynamics Connected App"

When access is revoked, Kernel loses the ability to make API calls immediately.

Is data encrypted?

Yes, at multiple levels:

  • In Transit: All API calls use TLS 1.3 encryption

  • At Rest: Data stored in Kernel follows your subscription's encryption policy

  • Credentials: API credentials stored in secrets manager with AES-256 encryption

  • Signatures: HMAC-SHA256 ensures request integrity and authenticity

What happens if our Dynamics environment is unavailable?

Kernel's fail-safe design handles downtime gracefully:

  • Automatic Retries: Up to 3 retry attempts with exponential backoff

  • Queue Management: Failed sync jobs are queued for retry when service resumes

  • Status Visibility: Downtime is clearly indicated in Kernel portal dashboard

  • Alert Notifications: Admin receives email alerts for extended outages

No data is lost during temporary outages; sync resumes automatically when service is restored.

Can we use this in Dynamics 365 Sandbox environments?

Yes. Kernel supports both Production and Sandbox environments:

  • Sandbox Version: Install the unmanaged solution for testing and development

  • Production Version: Install the managed solution for production use

  • Separate Tenants: Each environment can have its own Kernel tenant for isolation

The sandbox version uses different API endpoints (configurable via ngrok for local testing).

What's the difference between this and the Dynamics 365 Connector?

Kernel Native Integration (This):

  • Deep integration with custom plugins and UI

  • Application user with service principal

  • HMAC-authenticated API calls

  • Fine-grained security role control

  • Real-time sync with change tracking

Generic Dynamics Connector:

  • Uses standard OAuth with user credentials

  • Basic CRUD operations only

  • No custom UI or plugins

  • Limited permission control

  • Scheduled batch sync only

The native integration provides better performance, security, and user experience.

How do we handle custom entities?

Custom entities can be included in the sync:

  1. In Kernel Portal: Navigate to Settings → Integrations → Dynamics 365

  2. Add Custom Entity: Click "Add Entity" and select from your Dynamics entities

  3. Field Mapping: Configure which fields to sync (read/write)

  4. Security Role Update: Ensure integration user has access to custom entity

  5. Test Sync: Run test sync to verify configuration

Custom entity sync follows the same security model as standard entities.


Technical Specifications

API Version

  • Dynamics 365 Web API: v9.2

  • OData Protocol: OData v4.0

Supported Dynamics Versions

  • Dynamics 365 Online (SaaS)

  • Dynamics 365 On-Premises (2016 and later)

  • Power Apps (Dataverse)

Browser Requirements (for Custom Page)

  • Chrome 90+

  • Edge 90+

  • Firefox 88+

  • Safari 14+

Plugin Requirements

  • .NET Framework 4.6.2

  • Sandbox isolation mode

  • Async execution supported

  • Trace logging enabled


See Also

Last updated