Per-User Salesforce Module Permissions for Riva Sync and Riva Insight

Overview

Salesforce users may have different permissions for CRM objects, even when they use the same Riva connection. The service account used by that connection may also have broader access than the individual users.

Per-user module permissions allow Riva to evaluate each user’s Salesforce permissions and account for those differences when accessing CRM objects. This applies across all sync, including background synchronization and Riva Insight operations.

The purpose is to prevent Riva from attempting operations that the individual user is not permitted to perform, reducing avoidable permission errors.

When Is This Feature Needed?

This feature is useful when access to Salesforce objects varies between users.

For example, the service account used by Riva may have access to Leads, while only some users have permission to access that object. Without per-user permission handling, Riva may attempt Lead operations for users who do not have the required access, resulting in permission errors.

The intended behavior is for Riva to skip Lead searches and lookups for users without Lead Read access. Users with the required permissions should continue to use Leads normally.

The same principle applies to other supported CRM objects and operations.

Which Permission Sets Are Required?

No specific Riva permission set is required.

Riva evaluates the user’s existing Salesforce access through their:

• Profile.
• Assigned permission sets.
• Permission set groups.

Customers do not need to create or assign a permission set with a particular name to enable this feature.

Per-user module permissions reflect the user’s Salesforce access. They do not grant additional permissions or change the user’s Salesforce configuration.

Which Permissions Are Evaluated?

Riva evaluates the following object permissions:

These permissions are commonly referred to as CRUD permissions: Create, Read, Update, and Delete. Salesforce uses “Edit” for the update permission.

A user may have permission to perform some operations on an object without having permission to perform all of them. For example, a user may be able to read records but not create, edit, or delete them.

Contact Riva Support Before Enabling

This feature is available for Riva Cloud and Riva On-Premise.

Contact Riva Support before enabling or modifying the configuration. The setting must be applied in the appropriate configuration location. An incorrect configuration can affect login, system information responses, or synchronization behavior.

Riva Support will:

• Confirm whether the feature is appropriate for your environment.
• Apply the setting in the correct configuration location.
• Validate the permission information returned for individual users.
• Check the resulting behavior with users who have different Salesforce permissions.

How It Works

For the Riva Insight and Web API integration, Insight requests per-user module permissions during login using the following setting:

Sync.Crm.PluginCompatibility.UserModulePermissions.Enabled=true

When enabled correctly, the Web API includes per-user CRUD permissions in the GetSystemInfoResponse payload.

Each permission entry identifies:

No changes to CRM connection mappings are required to return this permission information.

The login response is the mechanism used to provide this information to Insight. Per-user permission handling also applies to background synchronization.

Salesforce Permission Sources

Standard and Custom Objects

For objects other than activities, Riva evaluates the object permissions associated with the user’s profile, assigned permission sets, and permission set groups.

Permission sets can grant access beyond the permissions provided by the profile. Evaluating the profile alone may therefore provide an incomplete view of the user’s access.

Activity Objects

Events, Tasks, and Emails require additional handling because their permissions depend on Salesforce activity permissions and the object used to store the activity.

Relevant permissions include:

• Access Activities, which controls activity read access.
• Event and Task permissions, which determine the permitted operations for those activities.
• EmailMessage permissions when Salesforce Enhanced Email is enabled.

Modify All Data

The Salesforce Modify All Data system permission is also considered when determining access to activity, standard, and custom objects.

Because this permission provides broad access, it can affect the permission information returned for a user.

Enhanced Email Behavior

The Salesforce Enhanced Email setting determines which CRM object is used for the Email module’s permission information.

Enhanced Email Disabled

When Enhanced Email is disabled, emails are synchronized as Tasks. Task permissions are therefore used for both the Task and Email SDK modules.

Example response:

[
  {
    "SdkModule": "Task",
    "CrmModule": "Task",
    "PermissionsCreate": true,
    "PermissionsRead": true,
    "PermissionsEdit": true,
    "PermissionsDelete": false
  },
  {
    "SdkModule": "Email",
    "CrmModule": "Task",
    "PermissionsCreate": true,
    "PermissionsRead": true,
    "PermissionsEdit": true,
    "PermissionsDelete": false
  }
]

Enhanced Email Enabled

When Enhanced Email is enabled:

• Task permissions apply to the Task module.
• The Email module maps to the Salesforce EmailMessage object.
• The EmailMessage permission entry is returned as read-only in the response shown below.

Example response:

[
  {
    "SdkModule": "Task",
    "CrmModule": "Task",
    "PermissionsCreate": true,
    "PermissionsRead": true,
    "PermissionsEdit": true,
    "PermissionsDelete": false
  },
  {
    "SdkModule": "Email",
    "CrmModule": "EmailMessage",
    "PermissionsCreate": false,
    "PermissionsRead": true,
    "PermissionsEdit": false,
    "PermissionsDelete": false
  }
]

These examples illustrate the permission response for the corresponding configuration. Individual users’ permissions may differ.

Financial Services Cloud Interactions

When the following setting is enabled, Riva uses the Salesforce Financial Services Cloud Interaction objects:

Sync.Salesforce.FSC.MeetingsAsInteractions.Enabled=true

The objects map to SDK modules as follows:

Example response for a user with full CRUD permissions:

[
  {
    "SdkModule": "RivaMeeting",
    "CrmModule": "Interaction",
    "PermissionsCreate": true,
    "PermissionsRead": true,
    "PermissionsEdit": true,
    "PermissionsDelete": true
  },
  {
    "SdkModule": "Participant",
    "CrmModule": "InteractionAttendee",
    "PermissionsCreate": true,
    "PermissionsRead": true,
    "PermissionsEdit": true,
    "PermissionsDelete": true
  }
]

Custom Objects

Salesforce custom objects are represented by their configured SDK Custom{#} modules.

For example, a Salesforce object named CallReport__c may be mapped to the SDK module Custom1.

The following example shows a user who can read records from that object but cannot create, edit, or delete them:

{
  "SdkModule": "Custom1",
  "CrmModule": "CallReport__c",
  "PermissionsCreate": false,
  "PermissionsRead": true,
  "PermissionsEdit": false,
  "PermissionsDelete": false
}

API Implementation Notes

Integrations consuming per-user module permission information should:

• Evaluate permissions for the individual user.
• Account for access provided through the user’s profile, permission sets, and permission set groups.
• Use both SdkModule and CrmModule to identify the relevant module and Salesforce object.
• Check the permission associated with the requested operation.
• Account for activity-specific permission handling and the Enhanced Email configuration.

Validation

After enabling the feature, Riva Support should validate users with different access levels.

For the Lead scenario, validation should include:

Validation should cover both background synchronization and Riva Insight operations.