Using setWorkflow in scoped application
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-15-2015 08:21 AM
Hi there,
I'm working on an application in Fuji in which I'm trying to create Software Catalog records from my app. I was able to create the records by enabling write access from all application scopes on the pc_software_cat_item table. However, I'd like to be able to avoid business rules and workflows running on insert/update. In trying to use the gr.setWorkflow(false) method from my Script Include, I receive this error:
Access to api 'setWorkflow' from scope 'x_my_app' has been refused due to the api's cross-scope access policy
Is there a way to allow this? Or another approach that is meant to take the place of this functionality? The scope limitations have proved to be a challenge. Thanks for any insight.
The script:
var newRecord = new GlideRecord('pc_software_cat_item');
newRecord.initialize();
newRecord.product_id = instanceObj.CMSoftwareID;
newRecord.name = instanceObj.Name;
newRecord.vendor = instanceObj.Vendor;
newRecord.sc_catalogs = defaultCatalogSysId;
newRecord.category = defaultCategorySysId;
newRecord.setWorkflow(false); // this triggers exception
newRecord.insert();
- 4,917 Views

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-15-2015 08:26 AM
It's best to think of these things in terms of everything outside your app providing an API. The API can expose CRUD, but you can't change the way the process behind the API works.
In short, you can't disable workflow on a table in another app because that would prevent the app from working as intended.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-16-2015 05:40 AM
Thanks James. I understand the rationale for default behavior, although not clear on why no way to grant access in cases where it is intentional and vetted (assuming there isn't such an option). Similar to the mobile consumer app store model that asks for specific permissions to the system, the idea would be to allow the app targeted access rather than treating it as a categorically foreign entity.
One other clarification, since I'm new to the API -- doesn't setWorkflow only affect the current operation? So at most the danger would be to "prevent the app from working" for this insert/update only?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-16-2015 06:15 AM
Cool. I don't think ServiceNow have thought that far ahead, and if they have it certainly isn't implemented as you have found.
.setWorkflow affects the GlideRecord instance it's called on, so not necessarily just a single operation (you might call insert/update/delete in a loop for example, and you could call setWorkflow outside the loop).