on top of the normal role restrictions for an interaction, there are other restrictions that can be put in place when there has been a restricted group entered on an interaction, it will make it so only people who are apart of one of the groups in this field will be able to read the restriction this is on top of the base permissions and security as described in interaction specific roles docid 16314kvr6jqyq7iuz1zwm automatically setting requested for and contact details within an interaction, when a requestor has been set and a requested for has not been set, the requestor will copy over to the requested for automatically in addition to this, every time a requested for has been set it will automatically populate the location, phone and email address of that user into the appropriate fields it copies it over, as it will allow the service desk to confirm any contact details in the system and update as required specific to this record, if for whatever reason the interaction is about that issue it should be noted though that every time a requested for changes, you will lose any changes in the location/phone/email fields finally, if the requestor or requested for is a vip (which is a flag found on the user record), the field itself will be highlighted with a purple border sla status on an interaction field, the sla status field will be set automatically from the primary sla associated to the interaction this will be updated as the sla updates target work generation when creating a new record from an interaction, it will read the reclassification field map table to understand what needs to be done depending on if an interaction is being resolved vs classified, will depend on the fields being brought across as part of the base system, the following fields are copied over for when you press the "classify interaction" button interaction field target table target field attached knowledge all attached knowledge client journal all client journal description all description email all email phone all phone location all location requestor all requestor requested for all requested for short description all short description source all source id all source interaction follower all follower in addition to this, the following fields are set when you press the "resolve interaction" button interaction field target table target field first contact resolved all first contact resolved n/a (this is scripted) all status (it will be completed for itsm requests/hr cases and resolved for incidents) there are other fields that may be set, but see the knowledge attachment capabilities section for more information first contact resolution to create a resulting record from an interaction, a user can either press the classify interaction or resolve interaction button the classify interaction button simply makes a new target record, whilst the resolve interaction button opens the target record and resolves / completes it (depending on the type) and populates the closure notes it then provides the user the option of being redirected to the new record with resolved interactions, as opposed to classified, there is the optional extra of setting different fields, however by default it will also set the closure notes knowledge attachment capabilities for resulting incidents attaching a knowledge article to an interaction can have certain effects to the resulting record if they are incidents if you attach a knowledge article to an interaction via sofi and the knowledge article is associated to a major incident (which is not resolved or closed), it will automatically related the resulting incident to the major incident this will then be bound by the rules as any other child incidents of a major incident in addition to this, if you attach a knowledge article to an interaction via sofi and the knowledge article is associated to a problem (which is not closed ), it will automatically related the resulting incident to the problem this will then be bound by the rules as any other child incidents of a problem