Cross-Scope access policy on a global scope table

[thinker]

I am writing a Custom Scoped Application. The application has logic to create, update and delete records in one of the Global scoped tables. However when it tries to delete a record, it gets a cross-scope error.

The reason is that the target table's Application Access does not allow delete (Can Delete unchecked). Understandable.

I read all about the Application Access Settings and understand that I shall create a cross-scope privilege record however the deletion is still refused unless the table's Application Access settings allow it. But then, if the table's Application Access settings allow it, then I don't even need the cross-scope privilege record.

I created a sample for it:

1. Created a new table in Global scope, MyTable, with a field, Name. Set the table's Application Access to AllApplicationScopes with CanRead, CanCreate, CanUpdate and AllowAccessToThisTableViaWebServices.
2. Create a new Custom Application, Test. Set the RuntimeAccessTracking to Tracking.
3. Create another Custom Application, Test2. Leave the RuntimeAccessTracking to None.
4. From within Test's scope, I execute a script to create a new record in MyTable:
   

   var rec = new GlideRecord('u_mytable');
   rec.u_name =  'A';
   rec.insert();
   
   // Adds cross scope privilege record for Execute operation on GlideRecord.insert
   // Adds cross scope privilege record for Create operation on u_mytable
   // It also adds the record in MyTable because there are these two cross scope privilege records with Allowed AND the table's Application Access allows CanCreate

5.  From within Test2's scope, I execute a script to create a new record in MyTable:
   

   var rec = new GlideRecord('u_mytable');
   rec.u_name =  'B';
   rec.insert();
   
   // No cross scope privilege records are created because RuntimeAccessTracking is set to None
   // But the record is still added to MyTable because table's Application Access allows it

6. Now from within Test's scope, I execute the following script to delete a record in Mytable:

   var rec = new GlideRecord('u_mytable');
   rec.addQuery('u_name', 'A');
   rec.query();
   if(rec.next())
   	rec.deleteRecord();
   
   // Adds cross scope privilege record for Read operation on MyTable.
   // Adds cross scope privilege record for Execute operation on GlideRecord.deleteRecord
   // However the delete is refused because the table's Application Access Delete is not allowed (CanDelete is unchecked)

7. Then from within Test2's scope, I execute the following script to delete a record in MyTable:
   

   var rec = new GlideRecord('u_mytable');
   rec.addQuery('u_name', 'B');
   rec.query();
   if(rec.next())
   	rec.deleteRecord();
   
   // No cross scope privilege records are created because RuntimeAccessTracking is set to None.
   // However the delete is refused because the table's Application Access Delete is not allowed (CanDelete is unchecked)

8. Looks like I have to enable CanDelete for table's Application Access settings. So I went ahead and did that.
9. Then I executed the delete script again in Test's scope:
    

   var rec = new GlideRecord('u_mytable');
   rec.addQuery('u_name', 'A');
   rec.query();
   if(rec.next())
   	rec.deleteRecord();
   
   // Adds cross scope privilege record for Delete operation on MyTable.
   // Deletes the record in MyTable because the cross scope privilege record exists and table's Application Access for CanDelete is set to true.​

10. Finally I went ahead and executed the delete script again in Test2's scope:
    

    var rec = new GlideRecord('u_mytable');
    rec.addQuery('u_name', 'B');
    rec.query();
    if(rec.next())
    	rec.deleteRecord();
    
    // No cross scope privilege records are created because RuntimeAccessTracking is set to None
    // The record is still deleted because the table's Application Access has CanDelete set to true​

Now if the table's Application Access is mandatory, why do I need the cross scope privilege records at all?

Also, the target ServiceNow instance's administrator may want to allow Test application to be able to delete records but not every custom application like Test2.

So how can an administrator allow certain applications on certain tables without opening them for modifications from every application?

Thanks,

Vipin

[thinker]

Hi @Brad Tilton,

Any insights on this?

Thanks,

Vipin

[Brad Tilton]

Generally it's considered a bad practice even for customers to delete anything in ServiceNow, the recommended approach is to set the record to inactive instead. The primary reason for that is once a record exists in ServiceNow, it can be referenced from somewhere else, and when the record is deleted the relationship is broken.

What kind of records is your app deleting?

[thinker]

Hi @Brad Tilton,

Thanks for the reply.

I'm writing an application which synchronizes data between ServiceNow and other inventory tools and synchronizes data e.g. in Computer (cmdb_ci_computer) table. Basically the app is installed in ServiceNow and other component of solution sends data to it. It then synchronizes the incoming data with data in ServiceNow tables using Import Set.

The app lets administrators choose if they want to create, update and delete records as part of this integration (basically defining source of truth).

Now if the incoming data says a Computer has been deleted in this third party inventory tool; this app shall be able to delete this Computer in ServiceNow. I define an additional column in Computer table to hold this state and mass delete all records at the end of import via a script. This is where the problem is, since the script runs from within a Scoped Application, it fails to delete the records.

We take care that the deletion is not done accidentally therefore ask customers to configure a property, defaulted to false. On top of that, I'm fine asking them to explicitly "say" this application is authorized to delete records. This "say" could be Allowing the Cross-Scope Privilege records or something else but would like to automate it as much as possible to avoid customers writing their own scripts to do it.

About cross-reference, I believe ServiceNow deletes all the relevant reference records just like any such tool would do. In fact, in my testing I have found that deleting a Computer record does delete the associated Asset etc. It does not delete e.g. the Company record which is exact what we want.

Thanks in advance for your insights.

Vipin

[Brad Tilton · Accepted solution]

Hi Vipin,

I understand the use case here, but the policy of not allowing store apps to delete any records is not something we would grant an exception for. I think the best you could do is have your app identify those records via a flag or setting them inactive, and then your customer can decide what to do with them. That could involve manually deleting them or just leaving them inactive.

Even with the asset/ci deletions oob, our recommendation is to only delete accets/cis in order to clean up errors. Once an asset or ci record exists in production it could have any number of task records open against it, which makes it much more difficult to delete.

[thinker]

Hi Brad,

One last thing, could you redirect me to the ServiceNow doc where it lists this limitation or behavior; store app can't delete the records?

I would like to share it with my Product Management and conclude this investigation.

Thanks a lot for all your help on the way 🙂

Regards,

Vipin