Business Rule for First Response (table agnostic)

[Adam Wencel]

I've looked through the following solutions for First Response in the community that do not solve my problem.  See below:

1. https://community.servicenow.com/community?id=community_question&sys_id=db7367e5dbc474102dc24f78139619d5
2. https://community.servicenow.com/community?id=community_question&sys_id=422b63b9dbe6a850ab0202d5ca9619fb
3. https://community.servicenow.com/community?id=community_question&sys_id=182cf55adb9190101cd8a345ca9619b7
4. https://community.servicenow.com/community?id=community_question&sys_id=90f247a1dbd8dbc01dcaf3231f961932

Most of them always give a partial and mainly incomplete solution, where First Response is tied to Additional Comments or Assigned To or SLA Response.  I've created a field in the incident table called First Response (date/time) to capture the change at time of logic.  See my thoughts below.

I don't want to dive into the scripting side of things and connect sys_journal_field and sys_audit and incident/sc_task/change/etc together and using the following logic in order to accomplish a simple task (which I can do, but I don't want to):

• State changes from New (if no other business rules are in place to interfere - ie, user responds and another business rule changes the state New to In Progress)
• OR State is not New and any other state due to the example above has interfered with the logic
• Additional Comments is not related to caller > User > Email
• Name, Element, Created by is not related to caller > User > Email (journal table)
• Table Name, Field Name, User, Old Value, New Value is not related to caller > User > Email (Sys Audit table)
• Updated By is not related to caller > User > Email
• Additional Comments is first in the Activity Log

I feel like this easy task is shrouded in the multi-verse of ServiceNow's normalized database configuration, schema, architecture, etc, and I'm wondering if I'm complicating this more than I should.  We have not done the following yet, but we could:

1. Fully Implemented SLA Management items
2. Fully Implemented Performance Analytics

We plan  to implement these eventually, but in the interim we want this first response visibility.  Am I missing anything here?  I feel like this is more complicated than what it should be for a basic industry standard that most ITSM platforms offer.

[Adam Wencel]

Thanks Tony, I never thought of using assignment groups. However, it still doesn't cover when an ITIL or Fulfiller creates their own tickets amd comments first. What you have in the script is pretty similar to what I was thinking. Do you have any solution or thoughts on how to identify a user versus fulfiller without having to define roles or groups?

[Tony Chatfield1]

Hi, I believe a fulfiller must have a role to be working within SNC user licensing agreement,
however a fulfiller can also be a user/requester.

It is possible to include a check to ensure the current logged in user is not the creator of the task with a small change to the if condition.

if (gs.hasRole('itil') && current.sys_created_by != gs.getUserName());

or you could use one of the other glideuser methods if you wanted to test reference fields like caller\opened by where the user sys_id is mapped

https://developer.servicenow.com/dev.do#!/reference/api/sandiego/server_legacy/GUserAPI?

[Adam Wencel]

Hi Tony,

Thanks for your suggestions above, but there is still some challenge to current and new tickets that break the logic.

• Current tickets may have 1 or more comments (so the conditions would populate false positive date/time updates into the u_first_response table)
• Because Journal comment entries cannot be called easily from a position according to the key value in the sys_journal_field table, the only way around this for current tickets would be to write a remedial fix first to capture all current system entries (let's say for the incident table) and write into the u_first_response field via methods using date/time or grabbing a "same as" updated date/time based on the 1st Additional Comment added by an analyst/fulfiller.

I mentioned identifying the poster of the comment not by role or group since the analyst/fulfiller could be updating the u_first_response field if they are the person opening the ticket (ie, the caller).  So licensing aside, I'm still trying to figure out how to address that logic for new tickets.

I'm currently using the glideuser methods to manage some of the conditions that I mentioned above, and that's why it can't be "opened by" since an analyst/fulfiller can open the ticket for the caller.

The current logic that you are suggesting doesn't address everything since it relies on roles and groups.  This is why I went down the route of the journal and sys_audit tables since they identify position in the Activity Log if you join them together correctly.

Again, thanks for your support so far.

[Tony Chatfield1]

Hi, if one of the trigger conditions for the BR is target field is empty then the BR can only run once, and once the field is populated it will not run again (unless the field is emptied) I have assumed your field is called 'u_first_response'? and so this would be covered by the condition  current.u_first_response.nil()
or you could use current.u_first_response == ''

I think there is also some confusion regarding the use functionality of sys_journal.

task comment\work_note fields can have only 1 entry at a time.
The journal is the target table for the content of comment\work_note type fields.
Every time a task is saved any comment\work_note entry is added to the journal and the task comment\work_note fields are emptied\reset.
But this is part of the save process and occurs when the record is committed to the database meaning that any comment/work_note entry is available in a before business by referencing the 'current' field and there is no need to access the journal.

[Adam Wencel]

Yes, you are correct on the journal entry regarding 1 entry as a time.  The reason I'm bringing it up is tied to my original post entry.  In the sys_journal_field table, the Name, Element, and Created By all are captured in correlation to a stored key value (highlight how it's linked to the Name) and the Created (date/time).  With current tickets in flight that have multiple journal entries and additional comments, there is no specific way to state when journal entry "comment" is 1st from Analyst (not user) - hence my reason to create a script with a loop to capture the information and from there call stored array values based on Analyst vs User.

It is true that for all "New" ticket created, the run once based on empty value will suffice.  However, it doesn't solve the User vs Analyst additional comment if the Analyst is the one submitting the ticket and updating it as a "User".  This would create a false positive.

For now, and please add any validation to this, I believe I will use some of what you suggested and also place a created date is greater than today.  That way, it will give me time to figure out how to update the u_first_response field properly (without false positives from the original BR) with the stored 1st Analyst entry from the sys_journal_field table.