> For the complete documentation index, see [llms.txt](https://docs.ins-pi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ins-pi.com/blueprints/admin-and-governance/servicenow-admin-guide.md). # 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. {% hint style="info" %} This page is technical reference for administrators, platform owners, security reviewers, and governance leads. End-user role behavior lives on [Roles and Permissions](/blueprints/start-here/roles-and-permissions.md). Data residency and security review topics live on [Security and Data Handling](/blueprints/admin-and-governance/security-and-data-handling.md). {% endhint %} ## 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 | Area | What it means in practice | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **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: | Role | Purpose | | --------------------------------------- | -------------------------------------------- | | `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) {% hint style="success" %} **New in 26.1.** See [Scheduled Audits](/blueprints/review-and-share/scheduled-audits.md) for what these features do. {% endhint %} 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. | Step | What | Why it matters | | ---- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | 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. {% hint style="warning" %} **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`: {% endhint %} | Column | Type | References | Label | | ----------------- | --------- | ---------- | --------------- | | `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`. {% hint style="warning" %} 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. {% endhint %} 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: ```bash ./scripts/repair-audit-notifications.sh --dry-run ``` 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. {% hint style="danger" %} 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. {% endhint %} The repository records all twelve rules and which exist, in `ServiceNow/BusinessRules/msp_set_domain_business_rules.json`. To create the missing ones: ```bash ./scripts/create-domain-business-rules.sh --dry-run ``` 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)](#domain-separation-msp). Make sure security and privacy reviewers have also read [Security and Data Handling](/blueprints/admin-and-governance/security-and-data-handling.md). ## 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ins-pi.com/blueprints/admin-and-governance/servicenow-admin-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.