Workflow Design Time Roles

v8.5

Overview

Workflow Design Time Roles define levels of access for users developing workflows in App Studio. There are several out-of-the-box Workflow Design Time Roles. You cannot modify or delete these roles. You can also create custom Workflow Design Time Roles.

Important Notes

• Design Time roles: these roles are applied on the workflow level, and are separate from roles defined in the Organization Settings section of the Administration site. 
• Global Admin role: (defined in the Organization Settings section of the Administration site) overrides any other permissions for a user, and has full permissions for the Administration site and organizational actions. For example, if a user is defined as a Global Admin on the organizational level, but denied the Edit permission for Design Time on a specific workflow, they will still have the ability to edit the workflow.
• Developer role: (defined in Organization Settings section of the Administration site) has full permissions for the workflow tree and Solutions, but requires additional permissions for specific tables (include lookup tables). On the workflow level, certain permissions can be denied to users with this organizational role. For example, if a user is defined as a Developer on the organizational level, and for a specific workflow they are denied permission to manage versions, they will not have the ability to manage versions for that specific workflow
• Design Time roles:
  • The default roles are Analyst, Support, and Workflow Developer. You can also create custom roles.
  • If you define a security role that denies the Set Runtime permission or the Design Time permission, it denies that user the ability to set those permissions for other users and themselves, in the workspace.
  • View only permission: when you assign users with view only permissions, they can still see all actions in App Studio and UX Studio and edit certain data, but these modifications will NOT be saved. When they try to save the workflow either the Save button will be disabled, or they receive a message explaining that they do not have sufficient permissions to perform this action. 
  • Edit permission: when you assign users with Edit permission, you must also assign them View permission, otherwise they will not be able to view the workflow in the tree and edit the workflow. 
  • Manage Version permission: can copy the workflow, requires Edit and View.
    • If the Edit permission  is also granted, users can:
      • Create a new version of the workflow in the same workflow space.
      • Restore a workflow.
      • Delete a workflow version if it is not the only version under the workflow space.
  • Attach Object permission: users can attach objects to the workflow.
• Workflow Developer role: in order to configure integration activities, you must also assign Read/Write permissions for this user on the relevant integration activity tables in the Administration site, such as WCF. Some activities only require Read permission.
• Lookup Tables: in order to create, edit, or delete lookup tables to a workflow, users require the Developer role. All users that have permission to edit a workflow can add an existing lookup table to a workflow.
• Integration Activities/Data Models: users that want to add or edit integration activities, or define service queries in a data model, require Read, Write, or Read/Write permissions on the table relevant to the service.
• Cora SeQuence 6 Form Activities: the new design time permission model is not supported in the Cora SeQuence 6 Form activity.

Permission Assignment Values

When you create a custom workflow security role, there are several assignment options for each permission. This applies to Workflow Design Time Roles and Workflow Runtime Roles.