¶ Designing Roadmaps
Key Note: In Planally, creating a "project" can mean creating a contract, tender, research initiative, product, audit, or any other entity defined by your workflow. The steps below apply universally, but examples here use projects for clarity.
Roadmaps define what's required in your workflow and what's set up automatically when your team starts a project. They arrange phases and activities so that every project follows a structured process, with the right permissions in place from day one.
¶ Overview
A roadmap is the sequence of phases and activities a project follows. When someone creates a project, they choose a roadmap and its structure is applied automatically. This ensures:
- All projects follow a standard process.
- Governance rules and activities are set up automatically.
- Teams know what's needed in each phase.
To open Roadmaps: go to Configuration → Projects → Roadmaps.
¶ Key Features
- Create Roadmaps: One per type of project (e.g. Major, Minor).
- Add Activities: Place activities in each phase.
- Set Permissions: Who endorses and approves each activity's status changes.
- Permission Inheritance: Default permissions for activities added to projects later.
- Manage Applicability: Mandatory, Prerequisite, or Applicable.
- Visualise Dependencies: Use Diagram View for complex roadmaps.
- Publish: Make changes available to projects.
¶ Creating a Roadmap
¶ Steps
- Go to Configuration → Projects → Roadmaps.
- Click Add Roadmap.
- Enter a Name, Color, and Description (all required).
- Tick Assignable to make the roadmap available for new projects.
- Click Save.
¶ Opening a Roadmap
Select the roadmap in the list and click Activities (shown with your workflow's activity term). The roadmap opens with its own Team and Settings buttons at the top, and two tabs:
- Roadmap Activities: the activities in each phase, and their settings.
- Permission Inheritance: default permissions for activities added to projects later.
¶ Adding Activities to a Roadmap
Add activities to each phase using the Table view (a structured list) or the Diagram view (shows relationships). The table shows each activity's Phase, Applicability, Swimlane, Priority, and whether an Endorser and Approver are set.
¶ Steps
- Open the roadmap's Roadmap Activities tab.
- Click Add Activity (shown with your workflow's activity term).
- Choose:
- Activity: one or more activity templates to add.
- Phase: e.g. Initiation, Planning, Execution, Closing.
- Applicability: Mandatory (must be completed), Prerequisite (required before others), or Applicable (optional but relevant).
- Swimlane and Priority (optional).
- Click Save & Next to add another, or Save.
¶ Updating Activities
Select one or more activities on the roadmap, then use:
- Update: change the phase, applicability, swimlane, or Priority (the order activities appear in).
- Permissions: who can be assigned, and who endorses and approves each status change (see below).
- Related Activities: links using Related, SS, FS, SF, or FF relationships.
- Delete: remove the activity from the roadmap.
¶ Setting Permissions
Permissions decide who can be assigned to an activity and whose sign-off is needed to move it between statuses. You set them in the Permissions panel, the same way for roadmap activities and for Permission Inheritance.
The panel has two parts:
1. Endorsement Policy and Approval Policy. Click the gear on each card (Manage Permission Policy) and tick the statuses where an endorser or approver is required: Not Planned, Planned, or In Progress. Each status refers to the move to the next status, so Planned means Planned → In Progress.
- An endorsement or approval succeeds when all named users, or one person in a named role, accept.
- It's rejected when at least one user or role endorser or approver rejects.
2. Role permissions. Click Add Permission and set, for a Role (roles come from the roadmap's Team):
- Assign in states: the statuses in which people in this role can be assigned (all on by default).
- Endorse in states: the status changes this role endorses.
- Approve in states: the status changes this role approves.
Click Save. The table shows each role's Assign, Endorse, and Approve settings for every status.
¶ Permission Inheritance
Permission Inheritance sets default permissions for each activity template, so that activities added to a project later (not from the roadmap) don't start without governance.
¶ How it works
- When someone adds an activity to a project, it takes the permissions set here for its template.
- It only fills in what's missing. If the activity already has its own permissions or approval steps, those are kept.
- Activities that come from the roadmap itself use their Roadmap Activities permissions, not these.
- Existing activities aren't changed.
¶ Steps
- Open the roadmap and click the Permission Inheritance tab. It lists every activity template in the workflow, with whether Endorsers and an Approver are set.
- Select one or more templates and click Permissions.
- Set the Endorsement Policy, Approval Policy, and role permissions, as described in Setting Permissions.
- Click Save.
- Publish the roadmap (see below).
When it takes effect: a project uses the Permission Inheritance from the roadmap version it's on. After you publish, projects need to update to the new version (from the banner on the project page) before activities added to them pick up the new defaults.
¶ Publishing a Roadmap
Changes to a roadmap, including permissions, only reach projects when you publish.
¶ Steps to Publish
- When a roadmap has unpublished changes, a bar reads Unpublished roadmap changes are available.
- Click Publish on the bar, or select the roadmap in the Roadmaps list and click Publish. Publishing happens straight away.
¶ What Happens After Publishing
- The roadmap is available when creating new projects (if it's Assignable).
- Existing active projects on this roadmap show a banner, Project Roadmap has new changes. People who can update the project see an Update button.
- Updates apply from the project's current phase onwards. Earlier phases aren't changed.
- Changes to a roadmap's name, description, colour, or Assignable setting only reach existing projects when you publish.
¶ Deleting a Roadmap
Deleting a roadmap is permanent and affects projects that use it. Instead, consider turning off Assignable so it's no longer offered for new projects.
¶ Steps to Delete
- Open the roadmap and click Settings. The Roadmap Settings panel opens, where you can also edit the name, description, colour, and Assignable setting.
- Scroll to Delete Roadmap.
- Type DELETE to confirm.
- Click Delete Roadmap.
¶ Best Practices
- Define roles before setting permissions.
- Set Permission Inheritance for every template teams are likely to add later, so ad-hoc work is governed too.
- Keep endorsement and approval to the steps that genuinely need sign-off.
- Publish only when a set of changes is complete, and tell project teams before they update.
- Use Diagram View to check dependencies on complex roadmaps.