Project inheritance, and the trap at the bottom of it

Project inheritance solves a real problem: five sites that want the same screens without five copies of them. It also has one behaviour that is easy to miss, and that Inductive Automation itself tells you to design around.

How it works

Project inheritance lets one project inherit resources from another. A parent is flagged as inheritable, a child names it in its Parent Project setting, and the child gets the parent’s resources without holding copies of them.

Two consequences follow immediately. Making a project inheritable sets Allow Overrides by default on all its resources, and an inheritable project cannot be launched as a stand-alone Perspective session or Vision client — try it and you get a “Project Not Runnable” error. That catches people: the moment you make the project you have been running inheritable, it stops being something you can launch.

Inheritance also nests. An inherited project can itself be made inheritable and become a parent, so a base project can feed a regional project which feeds a site project. That is genuinely useful, and it is what makes the counting below less obvious than it first appears.

Overriding breaks the link, until you discard it

To edit an inherited resource you override it, which recreates the resource in the child project. From that point, future changes to the parent’s copy do not propagate to the overridden one.

That is recoverable, and the recovery is worth knowing about. Right-click the resource and select Discard Overrides: the override is removed and the resource returns to its inherited state, following the parent again. Overridden resources also carry an Inherited Resource Overridden icon in the Project Browser, so they can be found rather than remembered.

This is the same shape as the UDT override problem we wrote about in UDTs: where they pay off, and where they trap you, including the resolution — the marker is right there in the Designer if anyone thinks to look. What it produces when nobody looks is the familiar afternoon: somebody changes the parent, four sites update, the fifth does not, and the fifth gets debugged as though it is broken.

New resources behave differently, and the distinction matters. Resources added to the parent do pass down to inherited projects. It is only the specific resources you overrode that stop listening.

One related gotcha: renaming an inherited resource in the child does not move it. The parent re-propagates the original, so you end up holding both the renamed copy and the inherited one.

The trap: runnable resources run in every leaf

Here is the behaviour that turns a tidy architecture into a support call.

Runnable resources — gateway event scripts, alarm notification pipelines, sequential function charts and transaction groups — execute in every leaf project, meaning every project that nothing else inherits from. Put a nightly gateway script in a parent that four site projects inherit from, and if each of those is a leaf it does not run once. It runs four times, and each execution believes it is the only one.

The count follows leaves rather than direct children, which is where nesting bites. A parent with four children, one of which is itself inheritable with two children of its own, has five leaves and therefore five executions — not four.

For a script that writes a report row, that is five rows. For one that sends a notification, five notifications. For one that posts to an external system, five of whatever that was, and the symptom shows up well downstream of the thing that caused it.

None of this is a defect. Inductive Automation documents it deliberately and advises designing around it. A leaf project that is enabled is a running project, and running projects run their resources. Projects do carry an Enabled flag, but disabling an entire project to stop one script is a blunt instrument rather than a fix.

Sorting resources by whether they run on their own

Views, styles and named queries are safe to inherit. They do something only when something calls them.
Project library scripts are nearly safe — but only if every line lives inside a function or class. Ignition executes a library’s module-level code when the library loads, which happens under several conditions and in each project’s scope — so a library with side effects at module level is a runnable resource in disguise. Inductive Automation recommends wrapping all project library code in functions or class definitions.
Gateway event scripts, alarm pipelines, SFCs and transaction groups need a decision: once for the estate, or once per site?
Reports are the awkward case. Inductive Automation’s runnable list does not include them, but report schedules execute on the gateway. If you inherit a scheduled report, verify the delivery count rather than assuming it.

If the answer is once for the estate, Inductive Automation’s advice is that the resource live in a leaf project or in a standalone project — one that does not participate in inheritance at all — rather than in the shared parent.

The Gateway Scripting Project setting is not the fix here, though it is the first thing most people reach for. Inductive Automation states that it has no impact on gateway event scripts defined in the Designer, because those are project resources and only run under their own project.

The wider point is that inheritance is a distribution mechanism, not a scoping one. It answers “where does this resource live”. It does not answer “how many times should this happen”, and it is a natural assumption that it does, because for everything that does not execute on its own the two questions have the same answer.

Worth checking on an existing setup

How many leaves sit below each parent that contains a runnable resource — not how many direct children?
Does anything scheduled write to a database, send a message or call an external system, and is the number of times it happens the number you expect?
Which resources have been overridden, and can any of them now be discarded?
Does any project library script have code outside a function or class definition?
Does anyone still have a shortcut to a project that is now inheritable, and gets “Project Not Runnable”?

Common questions

How does project inheritance work in Ignition?

One project inherits resources from another. The parent is flagged as inheritable and the child names it in its Parent Project setting. Making a project inheritable sets Allow Overrides on all its resources by default, and an inheritable project cannot be launched as a stand-alone Perspective session or Vision client.

What happens when I override an inherited resource?

The resource is recreated in the inheriting project, and future changes made to the original in the parent no longer propagate to it. The override can be removed by right-clicking the resource and selecting Discard Overrides, which returns it to its inherited state. New resources added to the parent still pass down regardless.

Do gateway scripts in a parent project run more than once?

Yes. Runnable resources such as gateway event scripts, alarm notification pipelines, sequential function charts and transaction groups execute in every leaf project, meaning every project that nothing else inherits from. A parent with four children, all of them leaves, executes four times. If one of those children is itself inheritable with children of its own, the count follows the leaves below it rather than the direct children.

Are project library scripts safe to inherit?

Only if all the code sits inside a function or class definition. Ignition executes a project library’s module-level code when the library loads, which happens under several conditions and within each project’s scope, so a library with side effects at module level behaves like a runnable resource.

Can a project inherit from a project that itself inherits?

Yes. An inherited project can also be configured as inheritable and become a parent itself, which allows multiple levels of inheritance and changes how many leaves sit below a given parent.