the interaction application has no roles set up specifically for it this was due to the factor that this is a wide reaching process that may cover many different processes as a result, it relies on the platform roles and system administration role to configure and use it accordingly how interaction's security works as the interaction application is used by multiple types of users from a range of business units, its security is slightly more open than most others from a role and permission setting however, as a consequence, administration of the application is left up to the system administrator to ensure no business unit alters the process for their specific unit's needs and get in the other way of others interaction permission type security model why was it set up like this? create an interaction any user with the self service role can create an interaction this was done as interactions are often the first step in the client interaction with the associated service desk or business unit however users are encouraged to create the end record type initially when possible (incident, hr case or request), but it would be seen as difficult to have the user understand what type of record they desire in the end read an interaction there are three levels of security for reading interactions see all interactions only administrators can see every interaction in the system see all non restricted interactions as a base to see all non restricted interactions, a user needs the platform agent role an interaction is restricted by the restricted group field therefore if a group or multiple groups have been entered into this field, a platform agent will need to be part of at least one of the groups listed to be able to see the record basic interaction visibility the basic level of visibility for interactions is where as users don't have the administrator or platform agent role, but have the platform self service role these users are only able to see records where they are the requested for or requestor in addition to this, users with only this role can never read information in the following fields worktype closure notes sla status attached knowledge assignment group restricted group | as this can cover all business units, only administrators can see all records, to ensure that sensitive data is not widely available when required although the restricted group is the only level of secondary restrictions, it still may cover a large number of interactions, if certain email addresses are found to only focus on specific business units the basic level of visibility however was set up with the intention that records that a user should be able to see, they are able to see, whilst restricting fields that serve no real purpose for the self service user or will provide details that should not be provided to prevent them contacting agents directly | \| update an interaction | any user with the self service role can edit an interaction, assuming they can read it to begin with | if a user can read the field or record, they can update the interaction therefore see the read section for the details around this | \| delete an interaction | only users who have the administrator role can do this | as interactions can cover a range of different units and it is recommended that interactions are not deleted from the system once created, this is shut down to only the administrator to ensure business unit's don't accidentally delete other business unit's records | recommended role allocation before allocating roles, remember to see what roles already include what roles automatically, as to not double up when managing the interactions process, there are essentially three main "personas" that align with this process naturally, this is the lowest level of security for each and can be changed, but these are what we recommend servicely system and global administrator description this is the user who manages the entire servicely instance for an organisation these are the users who can make any "administrative" changes to the interaction roles recommended all hr / service desk agent description these are the people who work day to day on the associated help desk, service desk or part of the hr team they can sometimes play a level 1 support role where they need to triage incoming tasks to the appropriate work type roles recommended platform agent platform selfservice +the appropriate role for their business unit (e g hr agent or itsm agent) any other user in the organisation description these are the users who are not a part of any service desk and don't complete any work on servicely they are a part of the organisation, but need to be able to raise interactions around hr, it issues or otherwise roles recommended platform selfservice