My tokens render as {{token}} instead of values

You generated a document and the rendered file has {{order.name}}sitting there literally, instead of the actual order name. The good news: this is almost always one of three fixable causes, and the engine surfaces literal tokens deliberately so broken bindings don't render silently as blanks.

1. The binding is missing

You typed the token into Word but never saved a binding for it. Templ8r doesn't guess — if there's no binding, it leaves the token as-is so you can spot it.

Fix

1. Open app.templ8r.co.uk/templates.
2. Open the template, click Visual mapper.
3. Look for the unbound token in the bindings table — it shows under "Unmatched".
4. Pick the column you want it bound to. Save.

2. The column logical name is wrong

You typed {{name}} but the entity's actual logical name isaccountname — common on customer-renamed columns. The binding looks valid but Dataverse returns null when queried.

Fix

In the visual mapper, the bindings panel shows confidence per binding. Anything showing low or unmatched on auto-suggest is suspect. Either the column doesn't exist on the entity, or you're typing the display name instead of the logical name. Replace with the correct logical name from the metadata browser (visible in the mapper).

3. Wrong relationship name (lookups)

For lookup tokens like {{customerid.name}}, the relationship name in the binding row must match a real navigation property on the parent entity. If you set it to customer but the actual nav prop iscustomerid, the engine walks an empty path and the token stays literal.

Fix

Use the polymorphic shortcut where possible — drop the type suffix and the engine fans out to all variants automatically:

• {{customerid.name}} — works for either Account or Contact
• {{ownerid.fullname}} — works for Owner (User or Team)

What if it's none of the above?

If the binding looks correct, the column exists, and the lookup nav prop is right, capture the rendered .docx + the template id and email it to support@templ8r.co.uk. This shouldn't happen — the engine has split-token normalisation (handles Word fragmenting {{ across runs mid-typing), so any genuine literal rendering is either binding-side or a regression we want to know about.