Roles

Last modified on 2023/07/26 15:16

Definition

A role is a dynamic variable used to assign actions to a Support person or Support group (groups / employees) without having to name each of them individually.

EndDefinition

Operating principle

  • You can use the Roles-Tags window icon.png icon found next to fields proposing the use of roles to access a list of roles. A data entry wizard will appear.
  • Each Support person/group is searched for when the role is called by the system so that the current value within the context of use is retrieved. The relevant users are identified by their name and email address. The value of the role (and Support person/group) can therefore vary each time it is called. You are however, not required to modify it each time.

example  Support person performing a workflow action identified when the action starts; Recipients of a notification email when an alert is triggered.

Classification of roles

"Domain"    Roles
  • These are functions that identify the Support person/groups performing actions in workflows (excluding CMDB) within the scope of their domain or function (location/department).
  • You can define the list of roles in reference tables in the Transition and Operation menus, by associating a group with a domain. Note: A group linked to the Whole company domain can intervene on all of the company's sites.

Syntax: #[WF_ROLE.Name of domain role]#

example #[WF_ROLE.Change Manager]#

Roles - Domain list.png
"Customized"    Roles
  • Roles created by customers when no existing role in any of the categories corresponds to customer requirements.

Syntax: #[CUSTOM_ROLE.Name of customized role]#

example #[CUSTOM_ROLE.Asset Owner]#

Roles - Customized list.png
"System"    Roles
  • Functions predefined in Service Manager, associated with a specific Support person/group.

Syntax: #[WF_ROLE.@Name of system role]#

example #[WF_ROLE.@CI Manager]#

Roles - System list.png
"CI"    Roles
  • Functions that identify the Support person/groups performing actions in workflows that process incidents/requests involving configuration items.
  • The list of roles is defined in reference tables in the Extended CMDB menu.

Syntax: #[WF_ROLE.Name of CI role]#

example #[WF_ROLE.Functional Manager]#

Roles - CI list.png

Examples

  • Roles in the Phone process workflow
    • The Analysis & Resolution step is performed by the Phone maintenance role.
             --> Including the #[WF_ROLE.Phone]# domain role enables you to identify the group of Support persons based on the location of the incident requestor.
       
    • The User Approval step is performed by the role identifying the incident requestor.
             --> the #[CUSTOM_ROLE.Requestor]# system role
  • Domain roles
    • Incidents are assigned to the Technician role.
    • They are handled by a different group based on the location of the user.
Role Domain Group
Technician

New York

Company 1

Boston

Company 2

HQ

Internal IT

Notes

  • When the SQL query associated with a customized role returns several values, only the first one will be taken into account.

Caution

  • To select a role in the data entry wizard, click the role you want and close the window. You are not required to click any button to validate.
  • In the event of an error, delete the instruction in the email manually and open the data entry wizard again.

Best Practice

  • To ensure that no syntax errors are made, you should use the data entry wizard to insert roles.
  • We recommend that you enter roles manually only if you are copying and pasting from an existing email in order to adapt the syntax to another situation.
  • Customized roles:
    • To reactivate a customized role, you should select an end date after the current date or clear it.
    • If you want a customized role to continue working correctly in existing elements but you want to make it unavailable for new elements, you should archive the role by entering an end date. You should not delete the role.
    • If you want a customized role to work correctly in alerts that return a list of records, you should always use the syntax in(@ID@ in the SQL query instead of =@ID@.

example  Create a customized role, Manager for financial approval of the requestor

SELECT AM_VALIDATOR.employee_id
FROM   sd_request
      INNER JOIN am_employee AM_REQUESTOR
              ON AM_REQUESTOR.employee_id = sd_request.requestor_id
      INNER JOIN am_employee AM_VALIDATOR
              ON AM_VALIDATOR.employee_id = AM_REQUESTOR.validator_id
WHERE  sd_request.request_id IN ( @ID@ )

Menu access

Administration > Parameters > Customized Roles

Screens description

Customized roles

         Role - step 1.png

Description: Name of the customized role.

End Date: The end of validity of the customized role after which it can no longer be used.

Context for a customized role

         Role - step 2.png

Table Name: Context where the customized role will be used.

example  A role associated with the AM_ACTION table can only be used for a workflow linked to the same table.

Data Type: Type of data returned by the SQL query.

  • Email: Email address
  • Employee: User login
  • Group: Group login

SQL: SQL query run when the role is called. It returns values based on the type of data specified.

  • The @ID@ variable identifies the current record.

Procedures and Wizards

How to specify roles in an email

1. Display the screen for creating an email.

2. Specify the roles you want.

   You can also enter the role you want manually. You must ensure that the syntax for the category is correct.

  • Click Roles-Tags window icon.png next to the fields proposing the use of roles.
             Roles - Workflow example.png
    The data entry wizard will appear.
  • Select the tab containing the role you want to insert. Open url.png See Description of categories
  • Click the role you want.
  • Close the window.
    The role syntax will automatically be inserted.
     

Modifying or deleting a role in an email

  • Delete the role manually.
  • Select it again as described in step 2.

How to create a customized role

Step 1: Create the new role

1. Select Administration > Parameters > Customized Roles in the menu.

2. Click Add icon.png.
 

Step 2: Entry the information

1. Enter the name of the role and the end date if applicable.

2. Click Finish.

3. Go to the Context tab and click Add icon.png.

4. Define the settings of the customized role.

5. Click Finish.

Wizards

Modify
Delete

 

List of system roles

Role Function Notes Corresponding Field/Tag
@Recipient Recipient of the incident or request
  • Specify this role if the recipient is different from the requestor.
  • Role generally used with action types such as Send Email (notify that the request has been taken into account), Self Service Approval (request evaluation or approval on the quality/speed of the intervention, with or without rating), Service Evaluation (request evaluation on the quality/speed of the intervention).
  • AM_RECIPIENT.LAST_NAME field in the Incident/Request form
  • Reference in an email: #RECIPIENT# tag
@Recipient and default Group Recipient of the incident/request and default group
  • The two roles are used together when an action is assigned to the recipient.
  • If the recipient does not belong to any group, the Group field will remain empty in the History of Actions.
  • Role referring to several fields: no associated tag
@Requestor Person reporting the incident/request
  • Role generally used with action types such as Send Email (notify that the request has been taken into account), Self Service Approval (request evaluation or approval on the quality/speed of the intervention, with or without rating), Service Evaluation (request evaluation on the quality/speed of the intervention).
  • AM_REQUESTOR.LAST_NAME field in the Incident/Request form
  • Reference in an email: #REQUESTOR# tag
@Requestor and default Group Requestor of the incident/request and default group
  • The two roles are used together when an action is assigned to the requestor.
  • If the requestor does not belong to any group, the Group field will remain empty in the History of Actions.
  • Role referring to several fields: no associated tag
@Closing Group Group performing the closing action, changing the meta-status of the incident/request to Completed
  • The closing group appears in the list of actions.
  • Any action using this role must be placed after the closing action so that the closing group can be identified.
  • LAST_GROUP_ID field in the SD_REQUEST table
  • Reference in an email: #CLOSING_GROUP# tag
@Group in charge of Release Group associated with the release project
  • AM_GROUP.GROUP_$lng field in the Release Project form
  • Reference in an email: #RELEASE_GROUP_MANAGER# tag
@Incident/Request Owning Group Group to which the person creating the incident/request belongs
  • If the Support person belongs to several groups, the owning group is selected randomly from the available groups.
  • Incidents assigned to the Support person's groups can be seen in Incidents > Incidents for my Groups.
  • AM_GROUP.GROUP_$lng field in the Incident/Request form.
  • Reference in an email: #OWNING_GROUP# tag or #GROUP_MANAGER# tag Note: These tags return the same value only when the Support person belongs to a single group.
@Catalog Group Group in charge of the incident/request using the topics defined in the incident or service catalog
  • AM_GROUP.GROUP_$lng field in the Incident/Service catalog
  • Reference in an email: #CATALOG_GROUP# tag or #GROUP_MANAGER# tag
@Submitted by Person who created the incident/request
  • Role generally used with the Send Email action type (keep the notification to trace the entry).
  • AM_SUBMITTED_BY.LAST_NAME field in the Incident/Request form
  • Reference in an email: #SUBMITTED_BY# tag
@Closing Support Person Person performing the closing action, changing the meta-status of the incident/request to Completed
  • The closing Support person appears in the list of actions.
  • Any action using this role must be placed after the closing action so that the closing Support person can be identified.
  • LAST_DONE_BY_ID field in the SD_REQUEST table
  • Reference in an email: #[DB_FIELDS.LAST_DONE_BY_ID.AM_EMPLOYEE.LAST_NAME]# database field
@Asset Owner Main user to whom the asset is assigned
  • The asset tag for the incident/request must be specified.
  • AM_EMPLOYEE.LAST_NAME field in the Equipment form
  • Reference in an email: #[DB_FIELDS.OWNER_ID.AM_EMPLOYEE.LAST_NAME]# database field
@Manager of Recipient's Location Manager of the location where the recipient of the incident/request belongs
  • All child locations of the location with a manager will inherit the same manager.
  • TMP_AM_MANAGER.LAST_NAME field in the Equipment form
  • Reference in an email: #RECIPIENT_LOCATION_MANAGER# tag
@Manager of Location of Requesting Person Manager of the location where the requestor of the incident/request belongs
  • All child locations of the location with a manager will inherit the same manager.
  • TMP_AM_MANAGER.LAST_NAME field in the Location form
  • Reference in an email: #REQUESTOR_LOCATION_MANAGER# tag
@Release Manager Support person associated with the release project
  • AM_EMPLOYEE.LAST_NAME field in the Release Project form
  • Reference in an email: #RELEASE_MANAGER# tag
@Recipient Department Manager Manager of the department where the recipient of the incident/request belongs
  • All child departments of the department with a manager will inherit the same manager.
  • Role generally used with action types such as Send Email (inform the manager that one of the team members has created a request), Self Service Approval (obtain the manager's approval for a request created by one of the team members).
  • TMP_AM_MANAGER.LAST_NAME field in the Department form
  • Reference in an email: #RECIPIENT_DEPARTMENT_MANAGER# tag
@Requestor Department Manager Manager of the department where the incident/request's requestor belongs
  • All child departments of the department with a manager will inherit the same manager.
  • Role generally used with action types such as Send Email (inform the manager that one of the team members has created a request), Self Service Approval (obtain the manager's approval for a request created by one of the team members).
  • TMP_AM_MANAGER.LAST_NAME field in the Department form
  • Reference in an email: #REQUESTOR_DEPARTMENT_MANAGER# tag
@Incident Owner Manager of the incident/request
  • By default, it is the person who created the incident/request.
  • Incidents assigned to the incident owner can be seen in Incidents > My Incidents.
  • AM_OWNER.LAST_NAME field in the Incident/Request form
  • Reference in an email: #OWNER# tag
@Recipient Manager Direct Manager of the incident/request recipient
  • Role generally used with action types such as Send Email (inform the manager that one of the team members has created a request), Self Service Approval (obtain the manager's approval for a request created by one of the team members).
  • V_MANAGER.LAST_NAME field in the Incident/Request form
  • Reference in an email: #RECIPIENT_MANAGER# tag
@Catalog Manager Manager in charge of the incident/request using the topics defined in the catalog
  • Role generally used with action types such as Send Email (notify that there is a new incident/request for the manager), Operation/Transition Processing (generate an action for the manager in charge of the topic), Self Service/Operation/Transition Approval (obtain the manager's approval in an approval step).
  • AM_MANAGER.LAST_NAME field in the Incident/Service catalog
  • Reference in an email: #MANAGER# tag or #CATALOG_MANAGER# tag
@CI Manager Manager of the CI involved in the incident/request
  • AM_EMPLOYEE.LAST_NAME field in the CI form
  • Reference in an email: #CI_MANAGER# tag
@Requestor Manager Direct Manager of the incident/request's requestor
  • Role generally used with action types such as Send Email (inform the manager that one of the team members has created a request), Self Service Approval (obtain the manager's approval for a request created by one of the team members).
  • V_MANAGER.LAST_NAME field in the Incident/Request form
  • Reference in an email: #REQUESTOR_MANAGER# tag
@@Manager of Group responsible for the Catalog Manager of the group in charge of the incident/request
  • Role generally used with action types such as Send Email (inform the financial approval manager), Operation/Transition Processing, Operation/Transition Approval (obtain the manager's approval for an incident/request related to the manager).
  • AM_MANAGER.LAST_NAME field in the Group form
  • Reference in an email: #CATALOG_GROUP_MANAGER# tag
@Manager for Financial Approval Direct Financial Approval Manager of the incident/request's requestor
  • Role generally used with action types such as Send Email (inform the financial approval manager), Self Service Approval (obtain the manager's approval for an incident/request related to the manager).
  • V_VALIDATOR.LAST_NAME field in the Employee form
  • Reference in an email: #FINANCIAL_VALIDATOR# tag
Tags:
Powered by XWiki © EasyVista 2024