Error: Execute operation on script include ‘todoPageUtils’ from scope ‘GRC: Risk Management’ was denied. The application ‘GRC: Risk Management’ must declare a cross scope access privilege. Please contact the application admin to update their access requests.
How to fix this issue?
Go to “Application Restricted Caller Access” (sys_restricted_caller_access) table
Change status to “Allowed”.
* Make sure you’ve captured the entry into your update set.
If you’re just starting your Next Experience journey, then you’ve come to the right place. This guide (Next Experience Quick Start Guide – ServiceNow Community) will help you understand what Next Experience is, how it works in tandem with our Workspace UI, and is a great place to return to as our products evolve over time.
Before you get started
Before you get started with Next Experience, check and consider the following documentation:
ServiceNow did an amazing job introducing workspace into our world, the links above are kind of live savers, they are so well documented full of best practises, recommendations and tips.
Current scenario
I am going to improve the “Response Tasks” on the Risk Portal. This our view from the backend (https://instance.service-now.com/nav_to.do?uri=sysapproval_approver.do?sys_id=0f676330db361d1021e7dd18f496195d). We have 2 OOB UI actions for record manipulation (“Update” and “Delete”) and 2 UI actions to update the state (“Approve” and “Reject”).
This is our current view on Risk Portal (https://instance.service-now.com/now/risk/portal/record/sn_risk_response_task/809623fcdbf21d1021e7dd18f496198a/sub/record/sysapproval_approver/0f676330db361d1021e7dd18f496195d). We still have the OOB UI actions, but we are missing the 2 UI actions to update the state.
Steps
Inspect the UI action “Approve” button to get the gsft_id.
Clone the UI action for “Approve” and “Reject”.
Create UX Form Action “Approve” and “Reject” and pointed to our custom UI actions. All these actions should be pointing to the sysapproval_approver table.
Create a UX Form Action Group (or UX Actions Layout Group) called “approval actions” where type = Split Button and actions are Approve and Reject.
In the UX Form Action Group record related items, create a new UX Form Actions Layout (sys_ux_form_action_layout_item) record. I named “Approval Actions” and this is responsible to display the button in the form.
Through the related lists of the UX Form Layout Item record, create a new Action Layout record. Focus on the “Action Layout Items”, that’s the most important thing here. This connection must exist.
The result will be:
Summary
The link How to use UI Actions in Workspaces – ServiceNow Community and Introduction to Declarative Actions – ServiceNow Community gave me enough to follow the breadcrumb trail and yes workspaces can be ready. We have few fields missing in the forms (we just need to update the view) and sometimes the UI actions do not behave the same but after few smoke tests the workspace can be ready. This is the perfect time to avoid lift and shift. This is a great o opportunity to re-imagine and improve the experience.
Bottom line is UI Actions are supported in both agent and configurable workspaces, but only in limited areas, such as the Action Bar component which is provided by default on the out-of-the-box record page. This means that UI Actions are only supported on forms in workspaces and not lists.
ServiceNow introduced a new concept called “Declarative actions”. What are they? Declarative actions are similar to platform UI Actions to add buttons on a form, etc. UI Actions are only exposed in the Action Bar component in Workspace, etc. experiences so the use cases are limited. Declarative Actions can be used in the Action Bar component on a record, related lists, lists, etc. without having to modify the page in UI Builder itself. By using Declarative Actions and not adding buttons to a page in UI Builder, you are making your upgrade experience better as Declarative Actions do not customize an OOTB UI Builder page. Instead, by creating Declarative Actions you are creating the necessary records needed in your own app scope.
A new version of the GRC plugins were published on the store, upgraded from version 14 to 15.
Plugin
Latest known version
Publish date
Compatibility
Release notes
GRC: Profile
15.0.3
Aug 04, 2022
RomeSan DiegoTokyo
NewAbility to have entity class rule based on a condition builderSync entity owner field to associated risks and controlsChangedsn_grc.reader role does not contain sn_grc.business_user role.sn_grc.user will contain sn_grc.business_user role.FixedIn child tables, the attachment option is accessible for non-confidential usersScript error coming from indicator_static_support_data_taskTypographical error in OOB GRC business rule script error messageGRC Developer role description must be updatedThe security-related properties under GRC Properties are not coming in orderThe user is also able to read the data of the parent user group when access groups are set as the child user groupACL added by the GRC: Profiles plugin is breaking the visibility of Information Objects in APMAll sys metadata tables required the update_sync attribute
GRC: Audit Management
15.0.2
Aug 04, 2022
RomeSan DiegoTokyo
NewCategorize Audit Engagements, Audit Tasks, Control Tests, etc. based on Functional Domains like IT Compliance and Risk, Privacy, etc.FixedWhen an Engagement is Closed Incomplete, related Control Tests are still Open.Audit Manager should not be allowed to Close an Engagement when related Tasks are Open.When we create a test template, unable to select the Control Objective field values which have lengthier display names.Security constraints on Client Callable script includes.When an Engagement is created from Entity form, newly created Engagement is not coming up in Downstream Engagements of Entity.
GRC: Advanced Risk Assessment
15.0.1
Aug 04, 2022
RomeSan DiegoTokyo
NewAssessors can evaluate controls by design and operational effectivenessFixedTranslation-related bug fixes
GRC: Common Workspace Elements
15.0.5
Aug 04, 2022
RomeSan DiegoTokyo
NewCategorize GRC Objects based on Functional Domains like IT Risk and Compliance, Privacy, etc.FixedTasks page — Tool tip of dropdown in “My group tasks” tab showing null Breadcrumbs aren’t showing the exact navigation in employee center when navigating to record from list view
GRC: Policy and Compliance Management
15.0.1
Aug 04, 2022
RomeSan DiegoTokyo
NewPerform Advanced Risk Assessments on Policy Exceptions.Categorize Compliance Objects like Policies, Authority Documents, Control Objectives, Citations, Controls, etc. based on Functional Domain like IT Compliance and Risk, Privacy, etc.The compliance Manager/Compliance Analyst should be able to reuse existing Evidences collected on other GRC objects.ChangedRole hierarchy changes: GRC Reader role will not be part of the Business User role. Changed all the ACLs, Modules, etc. accordingly.Added Expired substate for Closed Policy Exceptions to indicate Policy Exception is Approved and Valid to date has crossed.Reason code can be modified after Policy Exception is Approved.Policy Exceptions submitted from Service Portal or Employee Service Center should go through Verification Approvals when Verification Rule is configured.The Requester should be able to extend Policy Exception more than once based on a configuration property.FixedLocalization issues.Incorrect due date on Policy Acknowledgements.Manually Retired controls are moved to Draft state when the Policy is published.States in which Controls are considered to be Active.On Impacted Controls for Policy Exceptions: Add/Add all buttons are not coming up.On Controls, Open Issues are not updated when a new issue is created.Policy Exception is created even though Valid from and Valid to dates are the same.GRC Business user is able to move the policy exception to Analyze state even though verification approvals are configured.Description of auto-created Policy exception created from PACE exception is truncated.The Retire button should not be present on the KB article related to Policy.
If you haven’t used the new feature Policy and Compliance Integrator, roll your sleeves up – this is a game changer. Forget about transform maps to import Authority Documents, Citations and Control Objectives, this scripted REST api will do everything for you.
Go to Postman and create a new collection called “CIM API Collection”.
In the tab “Variables”, create a new variable inside the collection called “instance” with value “https://YOUR_INSTANCE.service-now.com”
In the tab “Authorization”, set up your REST api user and password. Dont forget in order to create new batches you need to be a compliance admin.
Go to sn_grc_provider table and create a new provider called “communityProvider”. If you don’t do it, when you create a batch it will create a new Provider import task and you need to complete few more steps in order to get the new provider generated.
Create a new POST method called “Create batch” with the following URL{{instance}}/api/sn_grc_cim/content/compliance/batch/create The body should be something like this:
Save the batch number because you are going to use it to create staging records or any interaction with the API.
Step 2 – Create the staging records
Go to Postman and inside your collection “CIM API Collection” create a new method called “Insert stagging records” with the following URL: “{{instance}}/api/sn_grc_cim/content/compliance/insert”
The body should contain something like this: {"batch_number":"CIB0001008", "records": [{ "document_id": "123456789", "name": "GRC Authority Document api", "description": "GRC Authority Document API", "citations": [{ "document_id": "123456789", "name": "GRC Citation api", "control_objectives": [ { "document_id": "123456789", "name": "GRC Control Objective api" } ] }] }]}
This code will generate one AD, one citation and one control objective.
3. Update batch to ready
Go to Postman and inside your collection “CIM API Collection” create a new method called “Update batch status to ready” with the following URL: “{{instance}}/api/sn_grc_cim/content/compliance/batch/ready”
The body should contain something like this:
{
"batch_number": "CIB0001008"
}
The end result should be something like this:
3. Kick process, review task and complete process
After this moment you need to kick the process by going to the Flow Designer, search for “Compliance staging processor” and run. Check the flow designer how often this process runs. Out of the box this runs weekly basis, every Monday. A new import task will be created after the flow has been executed.
Go to “Library import task” and review the staging records if necessary. At this stage, you can add an approver, or approver group, etc etc.
The new authority document with citations and control objectives will be created when the import task is completed.
If you need anything, please let me know and I can share the Postman collection to save you some time.
"Being a Jedi is not just about power, or lightsabers, or even skill with the Force. It is about connection. Being part of something bigger. I am stronger as part of the Jedi Order than I could ever be alone."
