Access Control on Modules

The integration modules allow you to set optional permissions for added access control to the activities that rely on the module. This way, only entitled users will be able to use the module, and therefore the integration, when building workflows.

note

Access control is only available for integration modules.

note

You can use multiple instances of a module to provide your Resolve Actions Express users with more flexible access to a third-party system.

For example, you could set up a pair of third-party system accounts with different levels of access - one with access to tables A and B and another with access to tables C and D. You could then use each to authenticate a separate module instance. Finally, you could give different Actions Express users access to each of the modules.

Implications of Restricting Access to Modules

As a user who is restricted from using a module, either fully or partially, you see the following implications on your work in Workflow Designer:

• When viewing a workflow that already includes activities that rely on the module, the activity settings behave as follows:
  • When you have read access only, you can see the settings but not change them.
  • When you don't have any access, the settings are not available for viewing or editing.
• If you don't have write permissions for a module instance when building or editing a workflow, the Activities palette grays out any activities that rely on the module instance, preventing you from adding those activities to the workflow. Similarly, these activities do not appear in the Activities palette search.
  note

  You will still have the full activity functionality if there is another module instance set up that does provide you with access.

• When setting up an activity that relates to the same module type, you only see the module instances that you have access to.
• When importing a workflow, and you are asked to select a replacement module to map to, you don't see restricted modules.

caution

The aforementioned restrictions do not apply to custom activities.

Default Module Permissions

If you don't set any permissions, all users have access to activities that rely on the module.

The Administrator role always has write access to the module and activities that rely on it.

Setting Module Permissions

The module permissions are available for setting while creating a new module or later when editing a module.

You have three options when configuring module permissions:

• Provide access to all users
• Provide access only to Administrator role users
• Provide access to specified users or groups, plus all Administrator role users

Take these steps to edit the permissions of a module:

1. Navigate to the permissions settings:
   • For an existing module:
     1. From the Main Menu, navigate to Configuration > Modules.
     2. Expand the Integrations section.
     3. Click the module that you want to edit and then expand the side panel on the right to view the module's settings.
   • For a new module: 4. From the Main Menu, navigate to Configuration > Modules. 5. In the Integrations section, click the plus icon to add a new module. 6. Follow the instruction in ::title to fill in the settings.
2. Expand the Permissions section.
3. Set the permissions:
   • To provide access to all users, leave the default selection of All users have access to activities using this module.
   • To provide access only to Administrator role users, click *Limit user access** but do not enter any security principals in the table.
   • To provide access to specified users or groups, plus all Administrator role users, click Limit user access and then add the users or groups that you want in the table:
     1. In the Type column, select the type of security principal that you are giving permissions to: User or Group.
     2. In the Name column, select the user or group.
     3. Check Read to provide read access to the module.
     4. Check Write to provide write access to the module.
     5. Continue adding users or groups until you have set the module's permissions the way you want to.
        To remove a security principal, click the X icon next to its name in the table.
4. Click Save.

Cumulative Permissions

Permissions granted to a user can be direct (granted to the individual user) or indirect (granted to groups of which the user is a member).

For example, if a group has Write privileges but User A's (a member of that group) individual entry only gives Read privileges, User A will have both Read and Write privileges.

Modules without Access Control

Not all integration modules offer access control. Modules such as Syslog, SNMP, and Message Queue - Microsoft that only provide events, don't have a Permissions section.

Limitations

The following limitations apply to the module permissions:

• The module selection field of Communication activities (Send Email, Send SMS, and so on) allows for passing a variable reference (like %moduleName%) instead of an explicit module name. If you are importing a workflow that includes such an activity, and you don't have write permissions for the referenced module instance, the activity will act as if you do.
• The Last Response activity always attempts to find a working communication module, starting with the default, and cannot be locked to a particular module instance. To that end, this activity does not support access control.