Blueprint Best Practices
A well-designed blueprint reduces rework, supports report consistency across periods, and makes it easier for contributors to enter accurate data. These guidelines are based on common patterns across project reporting implementations.
Design principles
1. Design for the data, not the output
The blueprint defines how data is captured. The output defines how it is presented. Keep these concerns separate:
- Do not add fields to sections just because they need to appear in a specific visual layout. Add fields because the data is needed.
- A section that is clean and correctly typed is easier to bind in the Output Designer than one that pre-formats values for a specific chart.
2. Use the narrowest field type
Avoid using Text fields for data that has a known structure:
- Numbers should be Number or Currency \u2014 not text.
- Dates should be Date \u2014 not text formatted as "01 Apr 2025".
- Status values should be Single select \u2014 not free text.
Strongly-typed fields enable filtering, sorting, aggregation, and conditional formatting in outputs. Free text fields do not.
3. Separate sections by data responsibility
Group fields into sections by who enters them and when:
- A Schedule Overview section filled by the scheduler.
- A Cost Performance section filled by the cost engineer.
- An Executive Narrative section filled by the project manager.
This allows section-level permissions so each role sees and edits only their own area.
Structural rules
| Rule | Reason |
|---|---|
| Limit repeating sections to one key dimension | A repeating section for activities should have one row per activity. Avoid nested repeating structures. |
| Keep single-entry sections for summary data | KPIs, headlines, and narrative text belong in single-entry sections. Detailed records belong in repeating sections. |
| Use Calculated fields for derived values | Do not ask contributors to enter values that can be calculated (e.g., SPI = EV/PV). Mark them as Calculated and define the expression. |
| Add descriptions to complex fields | Contributors should not need to ask what a field means. Use the field description to clarify units, scope, and data source. |
| Use Required sparingly | Only mark a field as Required if the report is genuinely invalid without it. Over-use of Required creates submission friction. |
Versioning
- Increment the minor version (e.g., 1.0 → 1.1) for additive changes (new fields, new sections).
- Increment the major version (e.g., 1.x → 2.0) for structural changes that break existing output bindings.
- Document the reason for each version change in the blueprint's Change log.
- Before publishing a major version, test all outputs against an edition created from the new version.
Reuse patterns
- Use Subreport components in outputs to embed standard sections (cover pages, glossaries, standard footer tables) maintained in a single child blueprint.
- Create a library blueprint for shared reference sections (e.g., a Risk Register section reused across project types). Import it using the section copy feature.
- Use consistent section and field names across blueprints so that multi-project outputs can aggregate across editions with matching field names.
Anti-patterns to avoid
| Anti-pattern | Better approach |
|---|---|
| One section with 40+ fields | Break into multiple focused sections by data domain. |
| Text fields for status values | Use Single select with a defined list. |
| Calculated values entered manually | Define a Calculated field expression. |
| Blueprint has no Description | Add a clear Description so library users know when to use it. |
| All fields Required | Reserve Required for truly blocking fields. |