Why placeholders are the heart of the system
Placeholders are what make a template reusable. Without them, the product would just store static letter text. With them, the same template can become hundreds or thousands of individualized documents.
What a placeholder does
A placeholder marks a value that will be resolved later. The value may come from employee data, company data, system-generated data, or requester input collected during the request flow.
Common placeholder categories
- Employee-derived:
[[employee_name]],[[position]],[[department]] - Company-derived:
[[company_name]] - System-derived:
[[reference]],[[current_date]] - Requester-supplied:
[[purpose]],[[recipient_name]]
Requester placeholders vs model placeholders
Requester placeholders
Use these only when the employee truly knows something the system cannot know in advance. They are flexible, but every extra requester field increases the chance of missing or inconsistent submissions.
Model placeholders
Prefer model-driven values whenever the data already exists in employee or company records. This reduces manual effort and lowers approval failures caused by missing user input.
Delimiter behavior
The seeded defaults use [[ and ]]. These delimiters are configurable in settings.
That flexibility is powerful, but changing delimiters later can affect template parsing across the whole system.
Placeholder design rules
- Keep names stable and descriptive.
- Use the same placeholder names in every language version of a template.
- Avoid creating near-duplicates like
[[employee_name]]and[[employee_full_name]]unless the difference is truly necessary. - Do not ask the requester for data the system already has.
Edge cases
- Delimiter change: can break parsing on older templates.
- Translation drift: one language may accidentally rename a placeholder.
- Requester-field overload: too many manual fields make approval slower and less reliable.
- Ambiguous placeholder names: weak names create confusion for template authors and approvers later.
Professional placeholder naming standard
- Use lowercase snake_case.
- Prefer business meaning over technical meaning.
- Keep names stable after templates are in use.
- Document unusual placeholders in the Examples or internal team playbook.
Good design heuristic
If a placeholder forces the reader to ask “where does this value come from?” it probably needs better naming or better documentation. The best placeholders are boringly clear.