Template Rules and Local Custom Fields Don’t Play Nicely 💔

English Forum Product Feedback
, , ,
1

We rely heavily on templates to standardize automation at scale, and there’s currently a conceptual inconsistency between how rules behave when duplicating a project versus creating a project from a template. That inconsistency limits how useful template‑based automation can be.

THE ISSUE:

When a custom field is added directly to a project template, that field becomes a local custom field on every project created from that template. That part works as expected.

Because that local field will exist in every resulting project, it seems reasonable to expect template rules to be able to reference it as a variable and, once the project is created, evaluate the local field within that project. Today, template rules can’t do this, which limits how much automation can be standardized through templates.

THE DUPLICATION PRECENDENT

This same pattern does work when duplicating a project—likely because the local custom field already exists on the source project at the time of duplication.

If a project contains local custom fields and rules that reference them, duplicating that project produces a new project where:

  • the local fields exist, and

  • the rules continue to function correctly.

From a user perspective, this establishes a precedent that rules can successfully reference local custom fields when those fields exist on the project being copied. Creating a project from a template is conceptually similar to duplicating a “master” project, but template‑based creation does not currently support the same automation behavior.

THE DILEMMA (duplication works better than templates in this key case​:grimacing:):

Templates are designed to be the scalable, first‑class alternative to duplication, yet in this case they support less automation than direct project duplication—pushing users toward the very pattern templates are meant to replace.

2

Interesting use case - is there a reason you want to use only local fields? We love a library field - less duplication of work on our end. And a Bundle is a beautiful thing for applying fields/rules in a standardized way.

3

Thanks for the question, @Beth_Seeber! Our main use case involves project template forms, where many questions are tied to template‑defined local fields that we’d like to use as variables in template rules.

Even if we built this for just one form in one template, we’d have many questions and, consequently, many fields. We don’t want to add that volume of highly specific, form‑only fields to our library, especially since fields used in forms can’t be made private. That would quickly clutter the field library with fields that aren’t intended for reuse beyond this template.

Using local fields lets us keep this logic scoped to the template, while still enabling automation based on form responses to capture project-specific details.