Authorization

A role consists of function-specific application displays. When you add users to HEAT, you assign them to one or more roles. Each role is organized as a set of permissions organized by common user functions. At login, the system prompts the user to select a role for this session, which governs access to HEAT modules and features (security rights) and access to business objects and fields (business object rights).

HEAT contains a default set of roles, including administrator, Service Desk Analyst, and various manager roles. You can customize these roles or create entirely new ones.

For example, a user logging into HEAT with the Change Manager role might view a layout of the change form that differs from the change form seen by a technician.  The Change Manager may also have access to dashboards displaying change request data recorded by the system over the last day and trending information for the week. You can link a role to a specific device, letting users log on to view dashboard data for those machines.

Another item to manage within the user interfaces area is the ability to grant roles. While there may be value in granting a manager the ability to grant roles with edit access to a subordinate, that same manager probably should not be able to grant access to the entire Configuration Console.

Business objects are designed with a set of default permissions for the following functions:

• View: View data.
• Add: Add data.
• Edit: Manipulate data.
• Delete: Delete data.

From the Configuration Console under Configure > Users and Permissions > Roles, you can create roles governing access to entire business objects. These are displayed as top-level tabs (such as incident, Problem, change, etc.) at the top of the user interface. See About Roles.

When granting access to a business object, be sure to grant access to its associated child objects. When a role has access to a child object, clicking Go To for a child record opens the associated child record in its own user interface. If not, the system does not open the object. You do not have to make the visible, only accessible.

When designing grids and layouts, be aware of role access to user interfaces. For example, if a role has access to a user interface, double-clicking on a child record in a user interface grid opens the associated user interface. If not, the record opens in a pop-up window.

As you construct a role, use the Object Permissions page to add levels of granularity for the role. You can set access rights at the field level by expanding a selected business object and adjusting the field permission set. To get to the Object Permissions page, from the Configuration Console, select Configure > Users and Permissions > Roles and Permissions. Double-click on a role name to bring up the Role Details page. Click Object Permissions to display the Object Permissions page.

When working with fields that involve pick lists, the contents of the pick list are defined, along with any restrictions, on the Pick Lists page.

By clicking Edit for a selected business object on the Object Permissions page, you can apply even more elaborate data-segregation constraints to do the following:

• Object links to the Profile.Employee (employee profile) object. For example, while a Service Desk Analyst can view all open incidents, you can use the Employee form (Profile.Employee) to assign a new employee to a particular team, such as Service Desk Analyst US which can only view incidents opened by customers located in the United States. You also can create a definition to make an incident view-only upon being closed by a Service Desk Analyst.
• Linked Profile.Employee object fields.
• Relationships linking the object to Profile.Employee (such as the Change Approval Board).
• Object links to objects or hierarchies that are also related to Profile.Employee. HEAT supports hierarchy structures for:
  • Organization unit
  • Team/department
  • Geography
  • Cost center

Use Hierarchical Structure

Use the hierarchy structure to manage permissions between tiers. For example, a member of a Service Desk Manager management-level tier could be allowed to view the incidents assigned to all Service Desk Analysts assigned to a lower tier.

If you are a member of more than one hierarchy, you have access to the most open set of permissions. For example, if you are a member of two teams, one with read-only access to a business object field and one with write access to the same field, you are granted write access to the field.

When constructing a form, you can combine business rules and field restrictions to help manage a workflow. For example, you can create a form that includes all of the fields in the change business object, but the fields viewed by a user are restricted based on the login roles. This is the simplest way to secure a form.

An example of using a business rule to secure a form would be to construct a business rule that prevents a Service Desk Analyst from editing a change request status once that request has been submitted and is in process. The Status field is rendered read-only on the request form. However, once the request has been processed and a change has been implemented, the field could be edited again, allowing the request to be closed.

Field restrictions that have been applied in the user interface are also applied to forms. For example, if you allow a pick list such as Status to be visible on an incident form, but not to be edited, the pick list remains view-only. This can interfere with successful completion of a workflow, as the status cannot be changed.

Use the Roles and Permissions page to manage the sharing of productivity tools with other roles. By publishing permissions, you can define dashboards, quick actions, or saved searches within one role and share them with another role. See About Roles.

These items also can be highly customized by the individual. Restricting such sharing can keep the application from becoming cluttered in places such as lists of available quick actions or saved searches. For example, a Service Desk Manager can have the ability (publish permission) to publish search results to Service Desk Analysts, allowing saved searches also to be accessed by the Service Desk Analysts.

Use care when planning to add powerful tools to forms such as quick actions. When added to a toolbar, they can often be used to circumvent form-related restrictions or pick lists which are constrained to limit selections for items such as status based on the current status value.