Team Roles
Clear role assignments make reporting cycles predictable and prevent access bottlenecks. Report Forge has five roles that map to distinct responsibilities in the reporting workflow.
Role overview
| Role | Scope | Core responsibility |
|---|---|---|
| Workspace Admin | Workspace-wide | Workspace settings, project creation, team access, governance policy |
| Report Owner | Project | Blueprint quality, edition cadence, final publication decisions |
| Designer | Blueprint | Blueprint structure, section layout, field configuration, output template design |
| Contributor | Edition | Data entry, evidence upload, edition submission |
| Reviewer | Edition | Comment, challenge, approve, or request revision before publishing |
Workspace Admin
Workspace Admins have access to all workspace and project settings. There should be at least two Workspace Admins at any time to avoid access lockout.
What Workspace Admins can do:
| Capability | Detail |
|---|---|
| Create and archive projects | Full project lifecycle management |
| Manage workspace members | Invite, role-change, remove |
| Configure workspace settings | Storage, branding, integrations, notifications |
| Manage data connections | Planner connections, SharePoint sync, API keys |
| View all blueprints and editions | Across all projects |
| Restore archived blueprints | Where a project team cannot |
| View audit logs | Full workspace-level audit trail |
Who should be Workspace Admin: IT/system administrator, document control manager, or head of PMO — not individual project managers.
Report Owner
The Report Owner is the accountable person for each blueprint and its recurring reporting cycle.
What Report Owners can do:
| Capability | Detail |
|---|---|
| Create and edit blueprints | Full blueprint design access |
| Publish blueprint changes | Including major structural changes |
| Create editions | Initiate each reporting cycle |
| Assign contributors and reviewers | Per edition |
| Close approved editions | Final act in the edition lifecycle |
| Generate and distribute outputs | PDF, Excel, Word, CSV export |
| Recall submitted editions | Return to Draft if needed before review starts |
Who should be Report Owner: Project manager, senior engineer, document control lead — whoever is accountable for the report reaching its audience on time and with accurate data.
Designer
Designers configure the blueprint structure and output templates. In many projects, the Report Owner and Designer are the same person — they are separated when the report structure is complex enough to warrant a dedicated configuration role.
What Designers can do:
| Capability | Detail |
|---|---|
| Design blueprint sections and fields | All field types, validation rules, conditional visibility |
| Design output templates | Output Designer components, layout, parameters |
| Publish blueprints | After owner approval |
| View all editions for their blueprint | For testing and debugging |
What Designers cannot do (without Report Owner role):
- Create editions (initiate reporting cycles).
- Close approved editions.
- Manage project team membership.
Contributor
Contributors are the people responsible for entering data each reporting cycle.
What Contributors can do:
| Capability | Detail |
|---|---|
| Enter data in assigned editions | Form mode and grid mode |
| Upload attachments | Files and images on edition fields |
| Save without submitting | Auto-save and manual save |
| Submit for review | When all required fields are complete |
| Respond to review comments | Update fields and reply to comments |
| Resubmit after changes requested | After addressing reviewer comments |
What Contributors cannot do:
- Create or modify blueprints.
- Approve editions.
- Access editions they are not assigned to (unless they also have Report Owner or Admin role).
- Generate outputs.
Reviewer
Reviewers perform quality control on submitted editions before outputs are generated.
What Reviewers can do:
| Capability | Detail |
|---|---|
| Open submitted editions for review | Full read access to all fields |
| Raise field-level, section-level, and edition-level comments | All comment types |
| Resolve their own comments | After contributor addresses them |
| Approve an edition | Moves edition to Approved |
| Request changes | Returns edition to Changes requested |
| Preview the output | Without changing edition status |
What Reviewers cannot do:
- Edit field values in the edition (they can only comment).
- Generate or publish outputs.
- Create or modify blueprints.
Role assignment scenarios
Small project team (3–5 people)
| Person | Role |
|---|---|
| Project Manager | Report Owner + Reviewer |
| Senior Engineer | Designer + Contributor |
| Engineer | Contributor |
| Client PM (external) | Reviewer |
Enterprise reporting function
| Person | Role |
|---|---|
| Head of PMO | Workspace Admin |
| Document Control Lead | Report Owner (all blueprints) |
| Report Analyst | Designer |
| Project Engineers (×4) | Contributor |
| Project Director | Reviewer |
| Client Representative | Reviewer |
Self-service project (small, agile)
| Person | Role |
|---|---|
| Project Manager | Report Owner + Designer + Reviewer |
| Team Members (×3) | Contributor |
Mid-cycle role changes
Changing a team member's role during an active reporting cycle requires care:
Adding a reviewer mid-cycle
- Go to Project Settings → Team → + Invite member (or change role).
- If an edition is currently In review or Submitted, open the edition and manually add the new reviewer as an assignee.
- The new reviewer receives a notification and can immediately participate.
Removing a reviewer mid-cycle
If the reviewer has already raised comments or approved:
- Their comments and decisions remain on the edition.
- Remove them from the Project Team — they lose access to future editions.
- If the edition requires all reviewers to approve, contact your Workspace Admin to determine if a workaround is needed.
Replacing a contributor mid-cycle
If a contributor leaves during data entry:
- Assign the replacement contributor to the affected edition in Edition settings → Assignees.
- The new contributor can see all prior saves and continue data entry.
- Remove the departing contributor from the project team.
Escalation paths
| Situation | Who to contact |
|---|---|
| An edition is stuck in review (no response from reviewer) | Report Owner → escalate to Workspace Admin |
| A contributor cannot submit (validation errors they cannot resolve) | Report Owner → review blueprint validation rules |
| A reviewer cannot approve (no Approve button visible) | Workspace Admin → check reviewer role assignment on the edition |
| Blueprint changes need to go live urgently during an active edition | Report Owner + Workspace Admin → coordinate with affected contributors |
| A member needs access to a historical edition they don't have access to | Workspace Admin can grant temporary project access |
Offboarding team members
When a team member leaves the project or organisation:
- Check active assignments: Does the departing member have any editions assigned as contributor or reviewer?
- Reassign contributor editions to another contributor.
- For reviewer assignments, add a replacement reviewer to active editions.
- Check blueprint ownership: Is the departing member a Blueprint Owner?
- Assign a new owner in Blueprint settings → Owner.
- Remove project access: Go to Project Settings → Team → remove the member.
- Remove workspace access (if applicable): Go to Workspace Settings → Team → remove the member.
The member's past contributions (edition data, comments, audit log entries) are preserved after removal. Their name appears in the audit log as the historical actor.
Role permissions quick reference
| Capability | Workspace Admin | Report Owner | Designer | Contributor | Reviewer |
|---|---|---|---|---|---|
| Create projects | ✓ | — | — | — | — |
| Create / edit blueprints | ✓ | ✓ | ✓ | — | — |
| Publish blueprints | ✓ | ✓ | ✓ | — | — |
| Create editions | ✓ | ✓ | — | — | — |
| Enter edition data | ✓ | — | — | ✓ | — |
| Submit edition | ✓ | — | — | ✓ | — |
| Approve / request changes | ✓ | ✓* | — | — | ✓ |
| Generate output | ✓ | ✓ | — | — | — |
| Close edition | ✓ | ✓ | — | — | — |
| Manage team | ✓ | — | — | — | — |
| Workspace settings | ✓ | — | — | — | — |
*Report Owners can approve editions only if they are also listed as an edition reviewer.
Related
- Reporting Governance — governance policy, naming conventions, and responsibility matrix
- Blueprint Governance — change control and blueprint lifecycle
- Notification Management — notification settings by role
- Project Management — creating projects and managing access