Code structure: Centralise code in shared parts
Intent
Use a Shared Part to maintain code that is needed in more than one template in one place, and include it wherever that logic is required.
Problem
Some logic is needed in more than one place. Duplicating that code across templates increases the risk of inconsistencies and makes maintenance and debugging harder, because every change must be applied everywhere.
Solution
Move shared logic into a Shared Part and include it from any template that needs it. Updates are then made once, in one location.
Structure
Examples / Applicability
Some examples:
- Account ranges A Shared Part with account ranges reused across templates. When the range changes, all templates stay consistent.
- Translations A Shared Part that centralises translations so wording stays consistent across templates.
- General variables / taxonomy logic A Shared Part that defines workflow-agnostic variables and taxonomy helpers used in multiple templates.
How to implement
- Define a clear scope: what the Shared Part is responsible for (and what it is not).
- Keep it focused (single responsibility) and document assumptions and expected inputs/outputs.
- Use a clear name that reflects the purpose (and follow naming conventions).
- Prefer workflow-agnostic Shared Parts when possible (workflow-specific ones are fine when justified).
Pros and cons
Pros
- Reducing code duplication: your code base is made smaller, as you avoid repeating code
- Improved maintainability: updates are only required in one place, minimising risks
- Enhanced readability: shared parts can be used to re-use specific coding, and thus making the overall code more concise and easy to understand
- Faster development: a shared part can be integrated into new development more quickly without the need to re-create the coding
Cons
- Over-generalisation: shared parts can tend to become too generic, making them harder to understand and use effectively
- Complexity: shared parts do require upfront planning and effort
- Debugging challenges: a change in a shared part might be hard to track down to which templates are impacted by the change
- Documentation: an overall view of shared parts and their purpose is required, to avoid new development leading into reinventing the wheel

