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]

I should add that I can probably do this in a script of the business rule using all of the above logic as well as the API reference for JournalEntry - https://community.servicenow.com/community?id=community_question&sys_id=704ccc501b364c18ada243f6fe4bcb11

I just need someone to validate if there is NO other option but to connect multiple tables together to extract a reference to an entry with all the conditions above.

If you feel you know the answer outside of scripting, then let me know.

[Tony Chatfield1]

Hi, unfortunately I am having issues following your post in it's entirety.
Perhaps you can start by defining 'First response' and the conditions that make this met?
Then exactly what you want to achieve when this condition is met, you want to populate a date/time stamp into your first response field? Once the requirement and drivers are clear the forum will be in a better position to advise.

[Adam Wencel]

@Tony Chatfield See below

Logic

Update First Response field in Incident table with timestamp of first response from an Analyst regardless of state or workflow in a ticket.

Conditions

1. Additional comments cannot be the caller
2. Additional comments must be the Analyst
3. Additional comments must be first of the Analyst entries in the Activity log
4. Updated by cannot be the caller (if I reference that in the scripting)
5. State can be either New or ANY OTHER state (depending on other BRs in place that dynamically update the incident based on conditions)

I will explain how I see First Response in the Activity Log of Incidents (for example).

First field that I see is Field Changes to introduce the ticket into the activity log.  I've avoided adding in all my "Filter Activity" items for brevity sake.  See below for the 1st entry in the log.

From here we could see 2 possibilities for Additional Comments (User vs Analyst), and that is captured with "Additional Comments".  See below for the "possible" 1st entry in the log.

Now, we don't know who this came from ultimately.  It could have been a User or Analyst, and you can't specify roles since some Analysts have ITIL roles and might need to submit tickets as users.  So, I've introduced the following tables in the equation from previous scripts and functions I've created:

1. Sys_Journal_Field (captures comments - ie, Additional Comments)
2. Sys_Audit (captures field changes - ie, States)

I have used the following community post to identify the API reference for JournalEntry in order to specify a specific entry that I want.  See link - https://community.servicenow.com/community?id=community_question&sys_id=704ccc501b364c18ada243f6fe4bcb11

I have other BRs in place that take a ticket from a Pending state and toss it into In Progress if the User replies back to the Analyst waiting for a response on a ticket.  The reason I'm mentioning this is due to the logic I presented earlier.  OOTB, New state of incidents (for example) changes to In Progress in the event a User updates an additional comment, so it breaks the logic.

I need to verify if there is an easier way.  Really, I need to stop reading 30+ community posts asking for the same item and getting partial solutions.

Will I have to:

a) Continue scripting into the ether of the multiverse of SN (didn't know that when we bought it)

b) Use another method outside the one listed above to achieve my end result

[Tony Chatfield1]

Hi, if adding this only for 'new' records you should not need to query journal or audit data,
but you would need to write a separate script if you wish to update existing records.
If you do need a remedial update then the 2 requirements should be separated as they are not the same thing.

For new records I would think a simple before insert\update BR, and based on your comments perhaps this would be appropriate
if the (additional) comments field changes and the update is by a user with role XXXX (probably ITIL ?) and the first response field is empty, then populate current day\time into first response.

Alternately you could reference assignment group membership instead of role, if a closer fit to your operations processes?

Something like this, you may need to update field name in script and condition.

BR
before() insert/update
Condition
current.comments.changes() && current.u_first_response.nil()

if (gs.hasRole('itil')) {
current.u_first_response = new GlideDateTime();
}