User mapping lets you connect Enginy people with Dynamics users. It is used to assign owners and, in certain operations, to write on behalf of the corresponding user.
Note: The user who connected Dynamics remains the entry point. Mapping another user does not grant additional permissions or bypass CRM security rules.
The three parts of User mapping
User Mapping overview in Microsoft Dynamics
Identities mapping
Connects the identities used to send campaigns with Dynamics users. This helps a campaign activity be associated with the correct sender.
Users mapping
Connects Enginy users with Dynamics users. It is used as a reference for exports started by those users and for operations that need to determine an owner.
Default CRM owner
This is the Dynamics user Enginy uses as a fallback when it cannot find a more specific mapping.
Default CRM owner selector
Important: An owner explicitly selected during an export may take precedence over these values for that operation.
Configure mappings
Go to
Integrations.Open Microsoft Dynamics with
Configure.Go to
User mapping.Connect each Enginy Identity or User with the correct Dynamics user.
Choose a
Default CRM ownerif you need a fallback.Save with
Save Changes.
Enginy gets the list of users visible to the connected user. If someone is missing, review Read on System User and access to that user in Dynamics.
How the owner is chosen
Depending on the flow, Enginy may resolve it in this order:
Owner selected in the manual export.
User or identity mapped for the operation.
Default CRM owner.
If no applicable value exists, the record may keep its current owner or Dynamics may assign it according to its own rules when creating it.
Write as another user
In some writes, Enginy uses Dataverse-supported impersonation to act as the mapped user. The operation only works if:
The connected user has
Act On Behalf Of Another User.The mapped user can create or modify the record.
Both users have sufficient access to related entities.
The intersection of their permissions applies. That is why the connected user may be able to read a record, while writing as the mapped user may fail.
Changing the owner also requires Assign on Contact, Lead, or Account.
Activities Enginy can log
Availability depends on the Enginy feature, Campaign mapping, and environment permissions.
Activity in Enginy | Record in Dynamics | Main condition |
Campaign email | Email activity | The campaign must be configured to log that activity. |
LinkedIn activity | Type selected in | If you do not choose another one, Email is used. |
Task | Task | The specific feature must create it and the user must have permissions. |
Call | Completed Phone Call | The specific feature must log it and Dynamics must allow creating and updating it. |
The integration does not automatically copy every Task or Phone Call from one system to the other.
Configure campaign activity
In Campaign mapping, decide whether an activity should:
Not be logged in Dynamics.
Be logged when it happens.
Be logged only after the contact replies, when that option is available.
Also configure the right Identity in User mapping. This allows Enginy to attribute the activity to the corresponding Dynamics sender.
LinkedIn Activity mapping
In Sync configuration, choose the activity type that will receive LinkedIn events. The initial value is Email.
If you select a custom activity:
It must be available in the connected environment.
The effective user needs Create and Append.
It must be possible to relate it to Contact, Lead, or Account as applicable.
Common permissions
Operation | What to review |
List users | Read on System User. |
Assign owner | Assign on the entity and access to the target user. |
Write as mapped user | Act On Behalf Of Another User and permissions of the represented user. |
Create Email | Create and Append on Email, plus access to related records. |
Create Task | Create and Write on Task. |
Log Phone Call | Sufficient privileges on Phone Call and its relationships. |
The Permissions panel checks privilege names, not their depth. A user-level privilege may not cover a record in another business unit.
If the owner or activity is not correct
Review in this order:
User or Identity selected in Enginy.
Corresponding mapping.
Default CRM owner.Owner selected in the manual export.
Read on System User.
Assign and Act On Behalf Of Another User.
Mapped user's access to the record.
Campaign or LinkedIn Activity configuration.
Test with a single activity and check the owner, Regarding, and activity type in Dynamics before enabling the flow for a full campaign.
When campaign fields reach Dynamics
Two things changed here recently, and they are worth stating plainly because the old behaviour caught people out.
Campaign Mapping fields do not depend on message logging
Conversations CRM Export controls whether messages are logged as activities. It does not control whether Campaign Mapping fields are written.
Important: The two used to be coupled. Turning conversation export off also stopped Sequence Status from updating, silently. They are now independent, and campaign fields mirror every send and reply whatever the message-logging setting says.
Sequence Status also syncs on enrollment, so it appears when the contact enters the campaign rather than only after the first message is logged.
Status also syncs on lifecycle changes
Status used to reach Dynamics only on message events. It now also syncs when you:
Pause or resume a contact.
Block a lead.
Add contacts to a campaign, or remove them from one.
A blocked lead is reported with a blocked status rather than dropping out of the sync.
Good to know: These syncs never fail the action that triggered them. Pausing a contact still works if Dynamics is unreachable, and the failure surfaces in the sync status instead.