> 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/work-in-the-app/templates.md). # Templates A template is a set of rules. Every blueprint inherits them. Good templates make structure consistent, planning faster, and compliance measurable. {% hint style="info" %} Templates are ServiceNow records under the `x_inpi_ydbp` scope. They follow your instance's standard ACL and audit behavior. Only [Blueprint Template Editors](/blueprints/start-here/roles-and-permissions.md) can create or modify them. {% endhint %} ## What a template controls
The Template Editor with two tables on the canvas joined by a Provided By relationship, and the template properties panel open on the right

A template is tables, the relationships between them, and the rules those carry

A template can define: * which ServiceNow tables appear on the canvas * which related lists are relevant * which fields matter for each table * which filters limit the visible data set * which relationships are available between tables * which minimum and maximum rules apply to records and relationships * the icon, name, description, and category users see on Home ## Create a new template From Home: 1. Open **Manage Templates** 2. Select **New Template** 3. Enter a **name** and **description** 4. Save the template 5. Continue configuring the template in the **Template Editor** After the first save, the template becomes easier to manage because actions such as **duplicate**, **delete**, and icon handling are available. ## The Template Editor The Template Editor has three working areas. ### Left: Add Table panel Use **Add Table** to search ServiceNow tables and add them to the canvas. You can search tables by business label or technical name, sort the list, and group by application scope. Expand a table to inspect related lists, or add several tables in sequence without closing the panel. ### Center: canvas The canvas is where you arrange the template visually. Drag and resize table cards, zoom and pan, and use snap-to-grid with alignment guides. You can also inspect suggested relationships between the tables you have added. ### Right: Data panel The Data panel changes based on what you select. When you select a table, the Data panel shows three tabs: **Rules**, **Fields**, and **Filters**. When you select a relationship, the panel shows the relationship configuration instead. ## Template details Use the template details view to maintain the template's **Name**, **Description**, **Category**, and **Icon**. ## Configure table rules In the **Rules** tab for a table, you can set how many records are expected. Common rule patterns are **optional**, **required**, **exactly one**, or **custom min/max**. ## Configure required fields In the **Fields** tab, you choose which fields matter for users when they work with blueprint records. This is useful when you want blueprint users to focus on a small, meaningful subset of ServiceNow data instead of every available field. ### Mark a field as audited Next to each selected field you can switch on **Audit this field for completeness**. An audit then reports records where that field is empty. This is separate from the **mandatory** marker you may see beside a field. That marker comes from the ServiceNow form and describes what the platform enforces when someone saves a record. Marking a field as audited is your own choice about what counts as complete data for this template. Only fields you have selected can be audited. If you deselect a field, it stops being audited, because a field the template does not show is not something a data owner can act on. ## Configure filters In the **Filters** tab, you define which records should appear in the blueprint experience. You can add existing ServiceNow filters or custom filter logic built in the template. Filters affect what users see in the **Data Hub** and help keep a blueprint focused on the right records. ## Configure relationships Relationships are the backbone of the template. The editor can show direct suggested relationships, inherited relationship suggestions, and related-list-based connections. For each relationship type, you can define rules in both directions. For example, you can tell the template how many Applications a Business Process must have, or how many Business Processes an Application may support. This is where minimum and maximum relationship rules belong. ### Require field values on related records Counting related records is often not enough. "Every Capability must have at least one related Business Application" is satisfied by an application that was retired years ago. Directly under each direction's cardinality controls you can add conditions on the related record. Only records matching those conditions count towards the rule. So you can require at least one related Business Application that is in production, or that is of a particular type. Each direction has its own conditions, sitting under the rule they qualify and headed **Which *****table***** records count**, because the related record differs depending on which way you are looking. {% hint style="warning" %} A condition here narrows what **counts towards this rule**. It does not decide which records may be placed on the canvas at all. That is the table's own filter, on the table itself. A condition of `Level = 3` on the relationship does not stop a Level 2 capability being added; it stops a Level 2 capability satisfying the rule. If you want a class kept off the canvas entirely, set it in [Configure filters](#configure-filters). {% endhint %}
The relationship panel: each direction's rule followed by its own condition section, one requiring Migration Strategy = Replatform and the other with no conditions

Each direction's conditions sit under that direction's rule. Here applications only count towards the rule if their migration strategy is Replatform

The field list is alphabetical, with the fields the template already selected first, since those are usually the ones a condition tests. Two rules govern how conditions combine: * Conditions inside a group are joined with **AND**. All of them must be satisfied by the **same** related record. A Capability linked to one production application of the wrong type and one correctly typed application that is not in production does **not** satisfy a rule requiring a production application of that type. * Groups are joined with **OR**. Use **OR**, beside **Add condition**, when either of two situations is acceptable. A rule with no conditions behaves exactly as before: it counts related records without looking at their field values. ### Limiting which records a rule applies to Counting conditions answer "which related records satisfy this rule". **Applies to** answers a different question: which records the rule is about at all. "Obsolete applications must have no capability mappings" is a rule about obsolete applications. Written as a counting condition it becomes "count only obsolete related applications", so every application is audited, and every application with no mappings passes — including active ones, which is the gap the rule exists to find. Set it in **Which *****table***** records this rule applies to**, above the counting conditions. A record outside the scope is not audited by that rule at all: it neither passes nor fails, and it does not count towards the compliance score. This is per rule. The table's [Filter](#configure-filters) scopes every rule on that table, plus the Data Hub and the canvas, so it cannot express "this one rule is about obsolete applications, the others are about all of them". **Applies to** can. {% hint style="info" %} Scheduled audits need the `rule_scope_query` column on `x_inpi_ydbp_audit_rules`. Without it the scope is discarded on save and every rule audits its whole table. See [ServiceNow Administration](/blueprints/admin-and-governance/servicenow-admin-guide.md#setting-up-scheduled-audits-261). {% endhint %} ### A condition applies to one direction only Each direction's conditions govern **that direction's check, and only that one**. Auditing an Application counts its Capabilities, so the conditions under **Which Business Capability records count** decide the result. Conditions on the Application side belong to the opposite check, the one that runs when a Capability is audited, and have no effect here. This catches people out when the rule reads like a scope. "Retired Applications have no Capabilities" cannot be written as a condition on the Application side of a relationship: every Application is still audited, and a live one with no Capabilities passes correctly, because 0 is within 0-0. To audit only retired Applications, put `Internal Lifecycle = Retired` in the table's [Filter](#configure-filters). The filter decides which records are audited; a relationship condition decides which related records count once one is. Where a rule carries conditions on both sides, the Auditor shows both, so you can see everything the rule asks for, and marks the one that did not apply to the check you are reading with **(other direction)**. ## Save, duplicate, and delete Use **Save** whenever you change template metadata, canvas structure, table rules, field selection, filters, or relationship configuration. You can also: * **Duplicate** a saved template to create a starting point for a variation * **Delete** a template if it is no longer needed {% hint style="info" %} Deleting a template is a governance decision. Existing blueprints based on that template can be affected, so the app warns you before deletion. {% endhint %} {% hint style="info" %} **Tips for designing templates** * Start with the smallest structure that still reflects the real process * Use categories so users can find the right template faster * Keep required fields focused on decision-making, not data overload * Use relationship rules only where they are meaningful enough to enforce * Test the template by creating a real blueprint from it before rolling it out widely {% endhint %} --- # 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/work-in-the-app/templates.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.