Templates

A template is a set of rules. Every blueprint inherits them.

Good templates make structure consistent, planning faster, and compliance measurable.

Templates are ServiceNow records under the x_inpi_ydbp scope. They follow your instance's standard ACL and audit behavior. Only Blueprint Template Editors can create or modify them.

What a template controls

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.

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.

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 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.

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.

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. 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

Deleting a template is a governance decision. Existing blueprints based on that template can be affected, so the app warns you before deletion.

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