[-]
  
  
  
  
  
[-]
  
  
  
  
[-]
  
  
  
[-]
  
  
  
[-]
  
[-]
  
  
  
  
  
 
Updated on 3/22/2019
Self Service & Analyst Portal - Community
Administration Settings
Direct link to topic in this publication:

This section describes the options found in the Administrator Settings

License Key

The first Administrator Settings are the Product key. When a valid product key is provided, the corresponding functionality will become available in the portal.

License Key Functionality

Analyst Portal: My Work, Team Work, Active Work, Search (including creating persisted search views), Configuration Items and RTF Knowledge Base view, New drawer menu for creating new work items,

Dashboards: Dashboards views. Work Item Grid Refresh Interval

The Work Item grid refresh interval controls how frequently the work item grid views automatically refresh. Keep in mind that many users having work item grid views open with a frequent refresh interval will have a potential impact on the ServiceManagement database.

Generally speaking, the larger the number of users the longer the refresh interval should be. A best practice is to start with a 5-minute refresh interval and change it to refresh more frequently and measure the impact on database performance and user experience.

Create New Work Items

These settings control the visibility of the New menu work item options. The New menu work item options are only shown if the Analyst Portal product key is entered and valid. By default all users that are members of the Analysts group entered during setup can see the New menu work item options. If the checkbox for a given work item type is unchecked, the New menu options will not be displayed for any user. If the checkbox is checked and a group is specified only members of that group will see the New menu options for that work item type. Normally, any analysts are allowed to create any type of work item and therefore the default configuration of the work item type checkboxes being checked and no groups being specified is sufficient because by default any analyst can create any type of work item. Specifying a group is only

 

useful to limit creating a certain type of work item to a subset of users in the Analysts group. In addition to an analyst user being granted permission to view the work item options in the New menu, the analyst user must also be included in a SCSM user role which grants the user permission to create work items.

A typical configuration would be to do the following:

  • Create an "Analysts" Active Directory group which contained all of the analyst users. The group can contain users or other groups.
  • Add the "Analysts" Active Directory group to the Advanced Operators SCSM user role. Alternatively, you could add the "Analysts" group to the following user roles: Incident Resolvers, Problem Analysts, Service Request Analysts, Change Managers, Activity Impllementers, Release Managers.
  • Specify the "Analysts" group during the setup of the Cireson Portal.
  • Leave each of the Create New Work Items checkboxes checked. Do NOT specify a group for each of the work item types

Note: the AD group (and any subgroups) must belong to the same domain as the cachebuilder service account, but may contain users from another domain.

Activity Settings

The activity settings control permissions to perform certain tasks on review activities and manual activities. By default, all users have permissions to perform these tasks. Specifying a group for these settings limits who can perform these tasks.

Manual Activity Settings

  • Mark as Completed/Failed controls the visibility of those statuses in the status dropdown of a manual activity.
  • Edit Activity controls whether or not the manual activity form fields are enabled or disabled.

Review Activity Settings

  • Approve/Reject and Add/Edit/Remove Reviewer controls who can see the buttons for performing those actions on the review activity form.
  • Edit Activity controls whether or not the manual activity form fields are enabled or disabled.

Assign Forms to Active Directory Groups

 

This section allows an administrator to target custom forms to groups of users in Active Directory so that depending on a user's membership in an Active Directory group and its assignment to a custom form, different users can see different forms for a given work item type. For example, you may want to present a form to HR service request analysts which shows some custom properties of the service request class which are specific only to HR service requests.

Another example might be to make some fields only editable for certain users.

 

When creating a form assignment, you need to enter the following:

  • Active Directory group name. This group must exist in the ServiceManagement database (the group, and any subgroups, must belong to the same domain as the cachebuilder service account, but may contain users from another domain). You can verify that it is present by running this query: SELECT * FROM CI$DomainGroup WHERE Username = 'the group name'
  • The ID of the custom form as defined in the work item .js file. For more information on creating custom forms, search the KB for 'custom forms'. Note: form names are case- sensitive.
  • The ordinal which is an integer that controls the order in which a form assignment is applied. For example, a user may be a member of more than one Active Directory group. Each of those groups may be assigned a different incident form. The form that is assigned with the lowest ordinal will be applied.
  • Form type - the type of form - incident, service request, etc.
  • The form projection ID. The ID of the SCSM type projection that defines the shape of the data (seed object class, properties, and related object classes) that will be pulled to populate data on the custom form and save the data back to SCSM on save/apply.

Assigning a user group, a custom form for a given work item type does not grant users that are members of that group to create, update, or delete data in SCSM using that form. The create, update, delete permissions are still controlled by SCSM user roles.

Team Requests View Groups

The Team Requests view is a special view provided out of the box that shows work items where the logged in user is the affected user and work items where the affected user is a member of any of the same specified 'Team Groups' as the logged in user.  For example, if Bob and Joe are both engineers in the Network Engineering Department, a group could be created in Active Directory and contain Bob and Joe. That group could then be added to the Team Requests View Groups in the Cireson Portal administrator settings. When Bob logs in to the portal and navigates to the Team Requests view, he will see work items where he is related to the work item as the affected user and also where Joe is related to the work item as the affected user.

The Team Requests view is also useful for scenarios where a service provider is supporting multiple customers and each of the end users in each of those customers’ needs to be able to view the work items created by people in their own company but not others.

Important notes:

  • The Analysts group specified during setup should not be used as a Team Requests view group.
  • These groups (and any subgroups) must belong to the same domain as the cachebuilder service account, but may contain users from another domain.