InEvent + Microsoft Dynamics Integration

2.0 Data Model & Entity Mapping

The connector writes data into standard Dynamics 365 entities and, optionally, into custom tables. It is Dataverse native, which means:

• Data is stored in the same logical and physical schema as your CRM data.
  
  

• You can use the same APIs, builders, and tools for event data that you already use for other CRM data.
  
  
  

2.1 Contact Resolution Logic

The integration uses a deterministic resolution strategy:

1. Primary key: Email address (InEvent registrant email).
   
   

2. Resolution steps:
   
   

• Check Contact entity
  
  

• If a Contact exists where emailaddress1 matches the InEvent email:
  
  

• Use that Contact as the primary party.
  
  

• All activities and event data are associated with this Contact.
  
  

• If no Contact match, check Lead entity
  
  

• If a Lead exists where emailaddress1 matches:
  
  

• Use that Lead as the primary party.
  
  

• All activities and event data are associated with this Lead.
  
  

• If no Contact or Lead match, create a new Lead
  
  

• A new Lead record is created with:
  
  

• Topic derived from event name or integration config.
  
  

• Core profile data and custom mapped fields.
  
  

• Downstream routing and qualification to Contact/Account are handled using your existing CRM processes.
  
  

3. Optional secondary keys
   
   

• The connector can optionally use additional matching keys such as:
  
  

• Company + Email
  
  

• External ID fields if present.
  
  

• However, the default configuration relies on email as the single unique identifier.
  
  

This preserves your existing CRM identity model while ensuring you maximize reuse of existing records.

2.2 Field Mapping Overview

Standard fields from InEvent are mapped to standard columns on the Contact or Lead entities, with additional custom columns for event specific data. A simplified mapping table is shown below.

2.2.1 Sample Field Mapping Table

InEvent → Dynamics 365 Dataverse

Notes:

• The new_ prefix represents custom columns in the Dataverse schema.
  
  

• The “Budget” question from the event registration form maps to a custom CRM field:
  
  

• InEvent: Custom Question "Budget" → Dynamics: new_budget
  
  

• The integration config UI in InEvent allows admins to add, remove, or update mappings to match their own Dataverse schema.
  
  
  

2.3 Activity Entities and Timeline Visibility

Event interactions are written as Activity records in Dataverse so that they surface in the Dynamics 365 Timeline control.

2.3.1 Activity Type

You can use either:

• A custom activity type, for example new_eventattendance, or
  
  

• A standard activity, such as appointment or phonecall, configured for this purpose.
  
  

Typical deployment uses a custom activity type with the following properties:

• Primary name: “Event Attendance”
  
  

• Logical name: new_eventattendance
  
  

• Activity type: Activity
  
  

2.3.2 Entity Relationships

Each Event Attendance record is:

• Related to a Contact or Lead via regardingobjectid.
  
  

• Optionally related to:
  
  

• An Account (company) record.
  
  

• A Campaign or Marketing Event record if you maintain those in Dynamics.
  
  

This ensures every InEvent interaction appears under the familiar Timeline UI:

• “Registered for: InEvent Product Launch”
  
  

• “Attended: Webinar: Securing the Cloud”
  
  

• “No show: VIP Executive Briefing”
  
  

2.3.3 Sample Event Attendance Columns

Minimal recommended columns for new_eventattendance:

• subject (Text): Event or session name.
  
  

• new_eventid (Text): InEvent internal event identifier.
  
  

• new_sessionid (Text): InEvent session identifier.
  
  

• new_sessionname (Text): Session title.
  
  

• new_registrationstatus (Option Set): Registered, Cancelled.
  
  

• new_attendancestatus (Option Set): Attended, No show, Partial.
  
  

• new_checkintime (DateTime).
  
  

• new_checkouttime (DateTime).
  
  

• new_engagementscore (Whole number or Decimal).
  
  

• ownerid (User or Team): Typically inherited from the Contact or Lead owner.
  
  

These columns are used directly in Power Automate triggers and in Power BI for reporting.

3.0 Power Automate & Workflow Triggers

Dataverse based storage ensures every new or updated record is eligible to trigger a Power Automate cloud flow. The integration design expects you to use flows for:

• Automated follow up tasks.
  
  

• Lead nurturing sequences.
  
  

• Notifications to sales or customer success teams.
  
  

3.1 Core Logic

The connector’s responsibility:

• Write or update Dataverse records with consistent, predictable fields.
  
  

Your responsibility in the Microsoft ecosystem:

• Define Flows that react to these records using the “When a row is added, modified or deleted” Dataverse trigger.
  
  

Common trigger entities:

• Contact
  
  

• Lead
  
  

• new_eventattendance (Event Attendance)
  
  

• listmember for Marketing Lists
  
  

3.2 Example Cloud Flow: Webinar Follow Up

This example illustrates a simple but realistic Power Automate cloud flow.

Goal
Whenever someone registers for a webinar, we want to:

• Create a task for the Contact or Lead owner.
  
  

• Send a confirmation and follow up email using Dynamics 365 Marketing or Outlook.
  
  

3.2.1 Trigger

Use the Dataverse connector:

• Trigger: “When a row is added”
  
  

• Table name: new_eventattendance
  
  

• Scope: Organization
  
  

Filter rows at the trigger level using the advanced options (if needed) by checking new_registrationstatus equals “Registered.”

3.2.2 Condition

After the trigger step, add a condition:

• Left operand: subject (Event Name from the Event Attendance record).
  
  

• Operator: “contains”
  
  

• Right operand: webinar
  
  

This isolates events whose name includes “webinar” so that the flow only runs for those.

If the condition is true, execute the following actions.

3.2.3 Action 1: Create Task for Record Owner

Use Dataverse action:

• Action: “Add a new row”
  
  

• Table name: task
  
  

Map fields:

• subject: “Follow up with webinar attendee”
  
  

• description: Compose a text string that references:
  
  

• Event name (subject from new_eventattendance)
  
  

• InEvent Event ID (new_eventid)
  
  

• Any key engagement metrics (e.g., new_engagementscore).
  
  

• regardingobjectid: Set to the Contact or Lead referenced in the Event Attendance record:
  
  

• Use dynamic content for the related record.
  
  

• ownerid: Use the owner of the Contact or Lead:
  
  

• Retrieve via a Dataverse “Get a row by ID” step if needed.
  
  

This ensures the appropriate salesperson or account owner receives a task in Dynamics 365 to follow up.

3.2.4 Action 2: Send Email via Dynamics Marketing or Outlook

You can use one of two options, depending on your stack:

1. Dynamics 365 Marketing / Customer Insights – Journeys
   
   

• Use a marketing email or journey that is triggered from a segment that includes event registrants, with the segment definition referencing the Event Attendance entity.
  
  

• Alternatively, use Power Automate to add the Contact/Lead to a specific Marketing List and let Marketing handle the actual send.
  
  

2. Office 365 Outlook “Send an email (V3)” action
   
   

• To: Contact or Lead email.
  
  

• Subject: “Thanks for registering for our webinar”
  
  

• Body: Include event details, calendar links, and next steps.
  
  

Using Marketing is preferred when you want tracking of opens, clicks, and nurtures.

4.0 Marketing Lists & Segmentation

Dynamics 365 Marketing Lists and segments are a natural control mechanism for outbound invitations and post event nurturing. The InEvent + Dynamics connector supports inbound and outbound use cases.

4.1 Inbound: Using Marketing Lists for Invites

Inbound here means data flowing from Dynamics into InEvent to control who you invite.

4.1.1 Static Marketing Lists as Invitation Sources

Admins can configure InEvent to consume Members of a Dynamics 365 static Marketing List as invitees.

Workflow:

1. In Dynamics 365:
   
   

• Create a static Marketing List, for example: “Q3 VIP Webinar Invites.”
  
  

• Add Contacts or Leads manually or via an advanced find.
  
  

2. In InEvent:
   
   

• Select the Marketing List as a source list for the event.
  
  

• The connector reads listmember records and resolves them to Contact or Lead records.
  
  

• InEvent generates and sends invite emails using its own invitation engine or provides registration links to those specific people.
  
  

Benefits:

• CRM users stay in their native interface when deciding who receives invitations.
  
  

• No Excel exports and manual uploads.
  
  

4.2 Outbound: Adding Attendees to Marketing Lists

Outbound means data flowing from InEvent into Dynamics 365.

4.2.1 Behavior Based List Assignment

The connector can automatically add participants to one or more Marketing Lists based on behaviors, such as:

• Registered but did not attend.
  
  

• Attended and engagement score above a threshold.
  
  

• Attended a specific session track.
  
  

Sample logic:

• If new_attendancestatus equals “Attended” and new_engagementscore greater than or equal to 70:
  
  

• Add Contact or Lead to Marketing List: “Hot Leads – High Engagement Event Attendees.”
  
  

• If new_attendancestatus equals “No show”:
  
  

• Add Contact or Lead to “No Show Nurture List.”
  
  

This is done via:

• Direct integration configuration in InEvent where list IDs are specified, or
  
  

• Power Automate flows that react to new Event Attendance records and use the Dataverse “Add a member to a list” action.
  
  

4.2.2 Downstream Segmentation

Because Marketing Lists and Event Attendance are both in Dataverse, you can:

• Use standard advanced finds to segment on event fields.
  
  

• Build segments in Dynamics 365 Marketing that reference:
  
  

• new_eventattendance as a related table.
  
  

• Conditions such as “Attended at least 2 events in the last 90 days” or “Has an engagement score sum above 150.”

6.0 Security & Governance (Azure AD)

Security, compliance, and governance in the Microsoft ecosystem are central to the integration design.

6.1 Single Sign On via Azure AD

Administrators and users can authenticate to InEvent using Microsoft 365 credentials via Azure AD SSO.

Key characteristics:

• OpenID Connect or OAuth 2.0 based SSO.

• Federation to Azure AD tenant.

• Support for MFA and Conditional Access policies defined on the Microsoft side.
  
  

Benefits:

• Centralized user lifecycle management.

• Fast onboarding and offboarding.

• Alignment with corporate password and MFA policies.
  
  
  

6.2 Service Account and API Permissions

The connector uses a service principal or dedicated application user. Permissions are configured at two levels:

1. Azure AD
   
   

• The app registration is granted appropriate API permissions for Dataverse/Dynamics CRM.

• Admin consent is performed once by a Global Admin or Privileged Role Admin.
  
  

2. Dynamics 365 Security Roles
   
   

• The service principal is mapped to an Application User in Dynamics.

• This Application User is assigned security roles that control:

• Which tables (entities) it can read and write.

• Whether it can create Contacts, Leads, Activities, and Marketing List members.
  
  

Policy alignment:

• If a security role does not allow access to certain VIP Contacts, the integration respects that. It does not read or modify records outside its permission set.

• This ensures that the connector does not circumvent line of business security controls.
  
  
  

6.3 Data Residency and Compliance

Because the integration writes directly to Dataverse:

• Event data is stored in the same region and tenant as the rest of your Dynamics 365 data.

• Your existing backup, retention, and audit policies apply automatically.
  
  

Auditing can be enabled on:

• Contact and Lead changes created by the InEvent application user.

• Event Attendance activity records.

• Marketing List membership changes.
  
  

This gives compliance and audit teams a single locus for review.

7.0 Implementation Guide (4 Steps)

This section outlines an end to end implementation at a practical level. Many customers complete initial setup in a single working session, with later refinements to field mapping and flows.

Step 1: Register App in Azure AD

1. Log into the Azure portal using an admin account.

2. Navigate to Azure Active Directory → App registrations.

3. Select New registration.

4. Provide an application name, such as “InEvent – Dynamics 365 Connector.”

5. Set Supported account types according to your policy (typically “Accounts in this organizational directory only”).

6. For redirect URI, if required for admin portal login, use the URI provided by InEvent.

7. After registration, note the:

• Application (client) ID

• Directory (tenant) ID
  
  

8. Under Certificates & secrets, create a client secret:

• Note the value securely. This will be used in InEvent.
  
  

Step 2: Grant Dynamics CRM / Dataverse Permissions

1. In the app registration, navigate to API permissions.
   
   

2. Add required permissions for:

• Dynamics CRM or Dataverse (depending on your environment and guidance from InEvent).

• Typically, application permissions such as user_impersonation or other Dataverse specific permissions.

3. Click Grant admin consent for your tenant.
   
   

4. In Power Platform Admin Center or Dynamics 365 admin center:
   
   

• Navigate to Environments → [Your environment] → Settings → Users + permissions → Application users.
  
  

• Create a new Application user.

• Use the Client ID from the app registration.
  
  

• Assign appropriate security roles:

• A custom role such as “InEvent Integration Role” containing:

• Create, Read, Write on Contact, Lead, Activity, Marketing List, List Member, and any custom tables used.
  
  

• Read on Account and related configuration tables as needed.
  
  
  

Step 3: Input Client ID / Tenant ID in InEvent

Within the InEvent admin portal:

1. Navigate to the Integrations or CRM configuration area.
   
   

2. Choose Microsoft Dynamics 365 integration.
   
   

3. Enter:
   
   

• Tenant ID (Directory ID).

• Client ID (Application ID).

• Client secret.

• URL of the Dynamics organization / Dataverse endpoint, such as https://org.crm.dynamics.com.
  
  

4. Test the connection:
   
   

• The connector will perform an OAuth 2.0 client credentials flow using the provided values.

• If the test succeeds, the connector is authorized to call Dataverse.
  
  
  

Step 4: Map Entities and Fields

In InEvent:

1. Go to the Mapping or Field Mapping configuration for Dynamics.
   
   

2. Map core identity fields:
   
   

• InEvent “First Name” → Dynamics firstname

• InEvent “Last Name” → Dynamics lastname

• InEvent “Email” → Dynamics emailaddress1

• InEvent “Company” → Dynamics companyname (Lead)
  
  

3. Map custom fields:
   
   

• InEvent custom question “Budget” → Dynamics new_budget

• Any other custom questions, URLs, or codes to custom columns.
  
  

4. Configure entity behavior:
   
   

• Contact resolution priority: Contact first, then Lead, then new Lead creation.

• Target entity for new records: Lead by default.

• Activity entity: choose or confirm new_eventattendance as the table for event activities.
  
  

5. Save and sync:
   
   

• Trigger a test registration in InEvent.

• Verify that:
  
  

• The Contact or Lead is updated or created in Dynamics.

• An Event Attendance activity record is created and visible on the Timeline.
  
  

6. Optionally, build initial Power Automate flows using the patterns described in section 3.0.

8.0 Technical FAQ

This section addresses common technical validation questions from Dynamics 365 Admins, CRM Architects, and IT Directors.

1. Does this work with On Premise Dynamics?

Answer: No. The integration is designed and optimized for Dynamics 365 Online and Dataverse.

Explanation:

• Authentication relies on Azure Active Directory and OAuth 2.0.

• API access is through the Dataverse or Dynamics 365 Online endpoints.

• On premise deployments using IFD or legacy authentication patterns are not supported by this connector.
  
  

If you have a hybrid scenario, standard practice is to consolidate CRM to Dynamics 365 Online before enabling this integration.

2. Can I map to custom entities?

Answer: Yes. The mapping engine is flexible.

Details:

• Any Dataverse table that is visible to the Application User and has permissions can be used as a target.

• You can:
  
  

• Map InEvent fields to custom columns on Contact, Lead, Account, or custom tables.

• Create custom activity tables for different engagement types, for example:

• new_webinarattendance

• new_inpersonattendance
  
  

• The configuration UI exposes a list of entities and columns retrieved from the Dataverse metadata.
  
  

You remain responsible for:

• Ensuring that custom entities participate correctly in your CRM processes.

• Defining relationships to Contacts, Leads, and Accounts where needed.
  
  

3. How fast is the sync?

Answer: Contacts and Leads are typically synced in near real time. Large volumes of engagement activities can be sent in batches.

Clarification:

• For low to moderate event volume, the default mode is near real time:

• Registrations and updates are pushed to Dataverse as they occur.

• This means Power Automate flows can react within seconds.
  
  

• For high volume events or heavy engagement traffic, such as thousands of check ins in a short period:
  
  

• The connector can operate in a batched mode for activity records.

• Batches run at a short interval, such as every few minutes.

• This reduces API overhead while still keeping data current.
  
  

IT teams can tune:

• Concurrency and throttling within the integration configuration.

• The balance between intantaneous updates and API consumption.
  
  
  

4. Does the integration support multiple Dynamics environments?

Answer: Yes, within standard Microsoft patterns.

• You can configure the connector against:
  
  

• A sandbox environment for testing.
  
  

• A production environment for live data.
  
  

• Each environment uses its own:
  
  

• Dataverse endpoint URL.
  
  

• Application user and security roles.
  
  

Recommendations:

• Use a separate Azure AD app registration per environment or environment specific configuration in the same app.
  
  

• Test mappings and flows in sandbox before switching production events to Dynamics.
  
  
  

5. How does duplicate management work?

Answer: The integration respects Dynamics 365 duplicate detection strategies and your Contact/Lead identity strategy.

• Primary key for matching is email address.
  
  

• Dynamics 365 duplicate detection rules can still be active:
  
  

• If a create operation would violate a rule, standard CRM behavior applies.
  
  

• If you use more advanced deduplication logic or third party tools, the connector can be tuned by:
  
  

• Sending minimal identifying information and letting CRM or external processes merge or normalize records after creation.
  
  
  

6. Can I restrict which events sync to Dynamics?

Answer: Yes.

• InEvent allows you to configure the integration at:
  
  

• Global level, or
  
  

• Per event level.
  
  

• For each event, you can choose:
  
  

• “Sync to Dynamics: On/Off”
  
  

• Whether to send:
  
  

• Registrations only.
  
  

• Registrations and attendance.
  
  

• Session level engagement.
  
  

This is useful when:

• You run internal events that you do not want in CRM.
  
  

• You only want customer facing engagement data to appear in the customer record.
  
  

7. How are deletions handled?

Answer: The connector focuses on additive and update operations.

• Deleting a registration or attendance in InEvent does not automatically delete related records in Dynamics by default.
  
  

• The recommended governance pattern:
  
  

• Treat Dataverse as the long term audit trail.
  
  

• Use status fields (e.g., new_registrationstatus set to “Cancelled”) rather than physical deletes.
  
  

If your organization has specific deletion requirements, you can handle them via:

• Power Automate flows that react to status changes and perform cleanup.
  
  

• Custom policies implemented in Dataverse.
  
  

8. What happens if Dynamics is temporarily unavailable?

Answer: The connector implements a retry and queueing strategy.

• If Dataverse or the Dynamics API is unavailable due to maintenance or transient network issues:
  
  

• New or updated event records are queued in InEvent.
  
  

• The connector retries based on a backoff schedule.
  
  

• Once the CRM endpoint is available:
  
  

• Queued records are replayed in order.
  
  

• The integration guarantees eventual consistency.
  
  

Operational teams can monitor:

• Error logs in the InEvent admin console.
  
  

• Standard telemetry and health metrics available on the Dynamics and Power Platform side.
  
  
  

9. How does this interact with Azure AD Conditional Access and MFA?

Answer:

• User SSO into InEvent respects Conditional Access and MFA policies.
  
  

• The backend application-to-application calls use the app registration and client credentials:
  
  

• Conditional Access and MFA rules targeted at human users do not block machine to machine authentication.
  
  

• You can, however, define Conditional Access policies for service principals if needed.
  
  

 

This integration is structured to align with Microsoft cloud patterns:

• Dataverse as the canonical data store.
  
  

• Azure AD as the identity and authorization layer.
  
  

• Power Automate and Power BI as the orchestration and analytics engines.
  
  

The result is that InEvent moves from being a disconnected event utility to an integrated signal source inside your Microsoft Dynamics 365 architecture.