ServiceNow Administration
Scoped. Governed. In-platform.
YouDesign Blueprints runs inside the customer's ServiceNow environment. This page covers what admins, platform owners, and security reviewers need to know about its runtime model, data stores, and access controls.
What YouDesign Blueprints is
YouDesign Blueprints is a scoped ServiceNow application with the application scope x_inpi_ydbp.
It runs inside the customer's ServiceNow environment and uses ServiceNow-hosted UI and backend components for blueprint design, review, and the Commit workflow.
Architecture at a glance
Application model
Scoped ServiceNow application under x_inpi_ydbp
Frontend runtime
UI loaded inside the ServiceNow shell under the scoped route /x_inpi_ydbp_app.do
Backend runtime
Scoped Scripted REST APIs and platform server-side scripts running on the ServiceNow instance
Primary data stores
Scoped application tables such as x_inpi_ydbp_templates, x_inpi_ydbp_blueprints, x_inpi_ydbp_blueprints_content, and per-user settings in x_inpi_ydbp_user_settings
Authentication model
ServiceNow session-based access. The application uses the active user's session and platform token.
Authorization model
Role-based access. ACLs and platform controls also apply.
What admins should know about the runtime model
The application runs entirely inside ServiceNow:
Users open the application through ServiceNow.
The UI is served inside the ServiceNow shell.
App APIs are called through scoped endpoints under
/api/x_inpi_ydbp/youdesign_blueprints/...Blueprint and template records are stored in scoped ServiceNow tables.
In other words, the application runs entirely on the ServiceNow platform, no external services or separate hosting required.
Main administration concerns
Access and role assignment
The main runtime roles are:
x_inpi_ydbp.blueprint_template_editor
Configure templates and governance
x_inpi_ydbp.blueprint_editor
Create and edit blueprint content
x_inpi_ydbp.blueprint_commit
Review and commit approved blueprint changes
x_inpi_ydbp.blueprint_viewer
Read-only access
As with any ServiceNow application, role assignment should follow least-privilege principles.
Data ownership and storage
The application stores:
Template definitions
Blueprint metadata
Blueprint canvas content and layout
Staged future-state and relationship work
Per-user application preferences such as theme, language, accessibility settings, favorites, and sort preferences
Platform governance
YouDesign Blueprints is not an external design tool that connects to ServiceNow. It is a scoped ServiceNow application with its own tables, endpoints, roles, and Commit workflow.
Architecture and enterprise review
The application is designed with several boundary controls in place:
Scoped app isolation through
x_inpi_ydbp.Role-based access to creation, editing, viewing, and Commit workflows.
In-platform persistence for templates, blueprints, and user settings.
Separation between normal draft saving and explicit Commit actions.
Backend-centric integration with ServiceNow data and metadata. The browser does not call external services directly.
These properties make the application easier to review for boundary control, access governance, and predictable behavior.
Setting up scheduled audits (26.1)
New in 26.1. See Scheduled Audits for what these features do.
Scheduled audits need tables and platform records that do not arrive with the application update. Until they exist, audits do not run and nothing else in the app is affected — each consumer checks whether its table is present and the hourly job logs what is missing.
Create them in this order. Each step is independently useful, so you can stop after any of them.
1
Table x_inpi_ydbp_audit_snapshots
Blocks the compliance trend and the summary report. Highest value, nothing depends on it
2
Script Include AuditSummaryReport
The periodic report
3
Table x_inpi_ydbp_audit_report_schedules
When that report goes out, and to whom
4
Notification columns on x_inpi_ydbp_audit_configurations
Per-schedule notification switches
5
Script Include RemediationTarget
Remediation record creation and validation
6
Table x_inpi_ydbp_remediation_targets
Where remediation work is written
7
Routing columns on configurations and findings
Links a finding to the record raised for it
8
Business rule on remediation targets
Refuses a mapping that would fail at audit time
9
Cross-scope write access to your remediation table
Without it, records are silently not created
10
Register the three notification events
10b
Column rule_scope_query on x_inpi_ydbp_audit_rules
Per-rule Applies to scope. Without it the scope is discarded and every rule audits its whole table
11
Three Notification records
The messages themselves. Set Send when to Event is fired on each
12
The hourly scheduled job
Runs audits, sweeps resolutions, sends reports
13
Column fallback_person on x_inpi_ydbp_audit_responsibilities
A fallback can be a person as well as a group
Column-by-column definitions, and the exact settings for each record, are in ServiceNow/Tables/AUDIT_SETUP.md in the application repository.
Step 13 fails quietly if you skip it. The endpoint accepts a fallback person and the audit runner reads one, so without the column the value is written to a field that does not exist, discarded, and gone when the form reloads — it looks like it saved. Add it as a Reference to sys_user, alongside the existing fallback_group:
fallback_person
Reference
sys_user
Fallback person
Access control
Audit tables follow the same pattern as the rest of the application: read for blueprint_editor, and create, write and delete for blueprint_template_editor.
The endpoints refuse audit writes from anyone without the template-editor role, but that only stops the application offering the action. The ACLs are the boundary — a blueprint editor can otherwise reach the tables through the platform UI. Confirm write access on the audit tables is restricted to blueprint_template_editor before go-live.
ACL changes need the elevated security_admin role and can only be made from an interactive session. Note that an ACL update attempted over the REST API returns HTTP 200 with a failure body, so a script that checks only the status code will report success while changing nothing.
Three traps worth knowing
A notification with an event name but the wrong Send when produces nothing, and says nothing. Setting the event name does not set Send when; a Notification created through the API keeps the default, Record inserted or updated. The event then fires, is marked processed, and no email is built — no outbox row, nothing failed, nothing ignored. Because the missing record looks like a sending problem, the time goes into SMTP accounts and the sender job, which are working. Set Send when to Event is fired on all three notifications, or check an existing instance with:
Drop --dry-run to set it. Safe to run more than once.
A scheduled job whose Run start is in the future never fires. Set the first run to a time in the near past or the next few minutes.
The report notification must branch on the no-runs flag. Compliance figures arrive empty rather than zero when a period measured nothing, and a template that formats them as 0% reports a collapse that did not happen.
Domain separation (MSP)
All twelve application tables carry a sys_domain column, and each needs a Set Domain business rule to populate it. Without one, rows are written with an empty domain, and on a domain-separated instance an empty domain is visible across domains.
The six 26.1 audit tables shipped without this rule: audit_report_schedules, audit_responsibilities, audit_rules, audit_runs, audit_snapshots and remediation_targets. On an MSP instance that means every customer's findings and runs are visible to every other customer. Create the rules before enabling scheduled audits on a domain-separated instance.
The repository records all twelve rules and which exist, in ServiceNow/BusinessRules/msp_set_domain_business_rules.json. To create the missing ones:
Drop --dry-run to create them. The script re-checks each table first, so it is safe to run more than once.
Each rule is a before insert/update rule gated on gs.getProperty('glide.sys.domain.partitioning') == 'true', so on a single-domain instance it never runs. There is no reason to defer creating them until domain separation is switched on.
Typical admin checklist
Before go-live or review sign-off, confirm:
The required Blueprints roles are assigned to the correct user groups.
The scoped application is installed and accessible through the intended ServiceNow entry points.
The required tables, Scripted REST resources, and supporting backend scripts are available in the target instance.
The intended users can save drafts, review compliance, and commit changes according to their assigned role.
If scheduled audits are in use, the objects above exist, write access on the audit tables is restricted to
blueprint_template_editor, and a test run produces findings and snapshots.A test run with notifications on produces one email per owner. Confirm this rather than assuming it, and confirm it before go-live: the failure mode is silence, which is indistinguishable from nothing having gone wrong.
On a domain-separated instance, every application table has a Set Domain business rule. See Domain separation (MSP).
Make sure security and privacy reviewers have also read Security and Data Handling.
What this page does not replace
This page is an overview. It does not replace:
your ServiceNow role-governance process
your instance-specific ACL review
your change-management process
your internal security approval workflow
Last updated