Case Updates for Internal Users

Question

Hello! 
 My organization is deploying Sugar Serve as our internal IT ticketing system and for submitting other internal requests. Employees who are already Sugar Sell users will be submitting cases through the Sugar Sell/Serve interface. For now, we are not using the case portal because we won't have any external customers submitting cases. I don't want to have Contact records created for each user as the system normally would for any cases submitted through the cases portal. 
 I'm trying to come up with a way for users to be notified when there are updates made to a case. Specifically, I want the user to whom the case is assigned to receive a notification if someone other than him/her makes an update to the case and I want the user who created the case to be notified when there is an update made by someone other than him/her. 
 Of course there is the out-of-the-box process definition that routes notifications based on update source (external or internal), but obviously that won't work since all updates are going to be made by internal users. 
 Any suggestions on how I could configure a process definition to route notifications to different internal users? Does anyone have any experience deploying Serve in this way (only for internal users)? 
 Thanks so much! 
 John

John Smith · Accepted Answer

Hi John Smith , 
 I'll cover the the use cases on how you would handle comment log updates and call out a few things to account for if you want to also have your users communicating through notes on a case. 
 Case Updated By User Who Is Not Assigned To The Case 
 This use case is relatively easy to address. With a single process definition. Your start event on the process definition would be set to 'Updated Records Only (All Updates)' and the criteria would be comparing the Modified By to the Record Owner as follows: 
 
 Once you add any additional criteria, you are on your way to create the desired notification to the assigned user. 
 Case Updated By User Who Is Not The Creating User 
 This use case is a little more complex because you cannot compare the Modified By user to the Created By user directly in a start event. To achieve this use case, there are a few options: 
 
 Combination of custom fields and sugar logic formulas on the Cases module that compare the related Modified By user and Created By user attributes. Those fields are then used in process definitions. 
 A custom logic hook written by a developer on-hand or by a partner such as us. 
 
 Option 1 gives you full control over the issue, but it is more complex to achieve. Here is how I recommend approaching that option: 
 
 Create a custom dropdown field on Cases (e.g. Notify Creating User - notify_creating_user_c) with dropdown list values of 'Yes' and 'No' 
 Create a custom, calculated text field on Cases (e.g. Update By Non Creating User - update_by_non_creating_user_c) with the following formula: ifElse(
 equal(
 concat(
 related($created_by_link,"first_name"),
 related($created_by_link,"last_name")
 ),
 concat(
 related($modified_user_link,"first_name"),
 related($modified_user_link,"last_name")
 )
 ),
 "No",
 "Yes"
) This formula is evaluting if the first and last name of the created by user equals the same values of the modified by user. If they are equal, the field value is 'No', and 'Yes' if they are not equal. 
 Create a process definition to trigger when Update By Non Creating User changes. The purpose of this field is to monitor any time this field changes, and depending on it's value update the value of your Notify Creating User dropdown. The start event would also be on all record updates and look like this: And the process definition would look like this: 
 Create a process definition to send notifications when the Notify Creating User dropdown field equals 'Yes'. As with the other process definitions, this will apply to all updated records with a start event looking like the following: Once you have this start event configured with all the desired criteria then you can feed that into the desired notification to send to the created by user. The purpose of separating this into two separate process definitions is that there may be consecutive updates to a case that should alert the created by user. 
 
 Considerations for Note Communications 
 When adding notes to a case, the case is not saved natively so you would need to either: 
 
 Use Sugar Logic fields to bring in the case's assigned user and created by user to the associated note records so you can do similar comparisons and process definitions 
 Use SugarBPM to populate the name of the created by user of the note to the case and then use SugarBPM to compare 
 Use a custom logic hook 
 
 One thing I would like to note is that our Upsert Notifications plug-in has a feature in our latest release where you can send notifications to users in Sugar via SugarBPM. The notifications would appear in the top right notification bubble, and optionally you could also choose the notification to generate a popup for the receiving user as well as receive an email. By using the notification feature within Sugar, you avoid your users having to context switch between email and Sugar and it can also reduce a lot of clutter in their email too. If you would like a demo of the plug-in, please let me know! 
 Chris