User permissions

In FootPrints, users’ access and actions are controlled by their user roles and user accounts. Users with similar needs or responsibilities are assigned user roles with the appropriate permissions. Individual user accounts can be further configured to refine access. Also, users can be grouped into teams that are assigned and managed as a unit.

User access is configured at two levels: System (for general access to the application) and Container (for specific access to data containers, their records, fields, and workflow processes). You can allow user roles to access:

  • Data containers (address books, CMDBs, knowledge bases, service portfolios, and workspaces)
  • Specific items (record types) in a container (contacts, CIs, solutions, services, tickets [such as incidents, problems, and change requests], and surveys)
  • Specific fields (making them editable, setting them as read-only, and hiding them)

Related topics

Configuring-user-roles

Configuring-users

User-roles-and-item-permissions

When workflows are used to automate standard processes, you can control how users participate at various stages. You can allow user roles to access:

  • Specific states in a workflow
  • Specific items in a container
  • Specific fields

Users who are not authorized to access particular areas of the application or certain data never see those areas or that data. For detailed information about how user access is managed in FootPrints, see User-management and Configuring-user-roles.

Permission settings

Configuring permissions at the role level makes it easier to manage user access. Permission settings range from:

  • Submit and read only (Customers)
  • Working assignments (Agents)
  • Administering containers and processes (Container Administrators)
  • All permissions (System Administrators)

The scope of permissions is represented in the following example.

permissions_scope_v2.png

The separations between Administrator and Agent permissions are malleable. You start with the default settings for a role and then allow and prevent access and actions to create an exact set of permissions. Users with Agent roles might be assigned:

  • Only those Agent permissions needed to perform their tasks (such as Financial Approvers)
  • Basic Agent permissions (such as Service Desk agents)
  • All Agent permissions plus some Administrator permissions (such as Service Desk supervisors)

Users with Administrator roles might be assigned:

  • Only those permissions needed to manage their data containers and perform related tasks (such as Container Administrators)
  • Basic Administrator permissions plus additional specific system permissions for assigned responsibilities (Agents and Managers)
  • All permissions (such as System Administrators)

For example, you might create one Agent role that creates, edits, and closes tickets and create another role that manages approvals for the team. In this case, for the first role, the default permission settings might be sufficient. For the second role, you could keep the default Agent permissions and assign additional voting permissions.

Users with Guest roles are permitted to create requests and view the resulting tickets. No other permissions are available for Guest roles.

The permissions provided for the other roles are more complex and are described in the following topics:

Next step

Download and review the Configuring users checklist attached to the Configuring-user-roles page.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*