Unable to create SLA definition for Security Request (sn_si_request) table

[Mike322]

Hi all,

Due to this thread not being able to resolve my problem, I was advised to create a new thread entirely. 
So if it helps, here it is.

The problem:

I'm in the Security Incident Response scope trying to create an SLA (OLA actually) definition for the 'sn_si_task' table. Yet this doesn't seem to be possible in the standard way as the form appears to be empty.

I've seen this happen at the client's instance but also in a clean activation of the SIR plugin on a clean PDI.

Steps to reproduce:

1) Have the Security Incident Response application installed;

2) Set the 'Security Incident Response' as the current scope;

3) In the navigator, type in: SLA definitions;

4) Click the 'New' button.

The result I get:

Trying a workaround:

Open up an existing SLA Definition (for example the OOTB 'SIR High Risk' SLA definition) and adjusting the fields. After inserting the record and staying on the form, all fields seem to get 'hidden' somehow. I can try and access the saved record again from the URL but all that shows up is an empty form. It's also not visible anymore in the SLA definitions listview either. When I create a background script to look for the record, I can still find it (all fields intact even). It's just gone in every other view.

@Allen Andreas Is this enough info for you to work with or do you need additional information?

@Anybody else: Have you had the same problem like this before and how did you resolve it?

Kind regards,

Mike

[Mike322]

Hi Chris,

Thank you for helping the search!

Unfortunately ServiceNow thinks that users need to have the certain roles in order to receive any kind of help. So when I click the first link you posted, I'm locked out of the solution for some reason.

The second link does work for me and I reviewed the ACL to which you were lead.

This helps me out greatly to get a hint to what is going on.

The ACL restricts users from creating SLA definitions on anything else than the sn_si_incident table. So my guess is that ServiceNow assumes you only want to define SLA's on Security Incidents and not on Response tasks and also don't want to give that extra flexibility. The reason for this seems to be undocumented though. But I'm glad to see that this can be resolved by resorting to the OOTB functionality only or disable the ACL as a workaround.

Thanks Chris for the insights!

Kind regards,

Mike

[Chris McDevitt · Accepted solution]

Hi, just a NEW ACL to cover sn_si_task based off of the sn_si_incident Read ACL

[Mike322]

This works. I also needed an extra Write ACL for the task table in order to make the fields writable.

As a workaround this works. But the fact that it OOTB doesn't work this way in San Diego (but did in Rome) is baffling and still worthy of a HI ticket to me.

Thanks anyway Chris! 🙂

[Mike322]

Hey Chris,

I've continued my research into this issue and it seems that it was working under the Rome release and everything since as long as you upgrade. Starting out with a clean San Diego release or installing the Security Incident Response plugin in the San Diego release will trigger this behavior.

In the Rome release, the ACL you posted is a little different: It'll say 'collection=sn_si_incident^EQ' while in the (clean) San Diego release variant it says 'table = sn_si_incident'. Maybe it's this little difference that's causing the problem (I'd think it'd work the same but it doesn't and this seems to be the only difference that I could find).

I'm creating a HI ticket in order to get this resolved. I'll keep this thread posted if I get a reaction there.

Kind regards,

Mike

[Community Alums]

Thank you for this! Same thing happening in Utah