Interaction specific roles

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 true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type 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