Roles


Roles are dynamic variables used to assign actions to a Support person or Support group (groups/users) without having to name each of them individually. 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 documentation icon EN.png  Support person performing a workflow action identified when the action starts; Recipients of a notification email when an alert is triggered.

  • 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.
  • To simplify their use, roles are grouped by category based on their context of use.

Classification of roles

"Domain"    Role
  • 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 documentation icon EN.png#[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 documentation icon EN.png#[CUSTOM_ROLE.Asset Owner]#

Roles - Customized list.png
"System"    Roles
  • Functions predefined in Product name - ev itsm.png, associated with a specific Support person/group.

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

Example documentation icon EN.png#[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 documentation icon EN.png#[WF_ROLE.Functional Manager]#

Roles - CI list.png

Examples

1. 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 and 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.

Best Practice big icon.pngBest 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 documentation icon EN.png 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@ )  

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.

Screens description: Customized roles

Menu access: Administration > Parameters > Customized Roles

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.

Define a context for a customized role

         Role - step 2.png

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

         Example documentation icon EN.png  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:

Best Practice icon.png  Click Roles-Tags window icon.png next to the fields proposing the use of roles.
         Roles - Workflow example.png
In the data entry wizard:

  • 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.
  • You can also enter the role you want manually. You must ensure that the syntax for the category is correct.

3. To modify or delete the role in the email, delete it manually and, if required, select it again as described in step 2.

How to create a customized role

1. Select Administration > Parameters > Customized Roles in the menu and click Add icon.png.

2. Enter the name of the role and the end date if applicable and click [ FINISH ].

3. Select the Context tab and click Add icon.png. Define the settings of the customized role and click [ FINISH ].

Wizards

Modify: Used to modify the customized role. 

Delete (Note: Only for elements not used in the application): Used to delete the customized role.

 

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:
Last modified by Unknown User on 2017/01/09 15:07
Created by Administrator XWiki on 2013/03/25 18:11

Shortcuts

Recent Updates

Haven't been here in a while? Here's what changed recently:

-   Product name - ev itsm.png
-   Product name - ev sas.png

Interesting Content

How to Automate Integration
Add a Shortcut to an App
History
Quick Dashboard
Full text search - Stop Words

Powered by XWiki ©, EasyVista 2018