Upcoming Release

This release is strongly focused on helping PMOs strengthen governance without making delivery processes harder to run in practice. Many of the updates in this release are designed to give organisations better control over how projects move through gates, workflows, reporting, and review points — while still allowing teams to adapt when circumstances change.

You’ll see a particular emphasis on governance flexibility and oversight: stage gates can now support more nuanced scenarios, including restartable approvals, informational gates, and externally managed workflows; new checks help identify when schedules or impacts may no longer be receiving enough attention; and audit history has been improved to make governance activity easier to review. Alongside this, we’ve introduced tighter controls in areas such as confidential project access, risk and issue management, protected schedule structure, and status reporting quality.

For PMOs, the overall theme is clearer governance, better traceability, and more practical control across the project lifecycle. For project teams, these changes help reduce manual work, improve consistency, and make it easier to work within the governance approach your organisation has defined.

Each stage gate can be configured with a Restart Policy that controls whether — and by whom — a gate's approval decision can be restarted. This is particularly useful when project circumstances change after a gate decision has been made — for example, if new risks emerge or deliverables have been reworked — giving PMOs the flexibility to re-evaluate at a gate without needing to create a new process.

The Restart Policy setting is available in the gate administration area and applies exclusively to gates using the Approval gate mode; gates configured as Declared, Informational, or External Workflow will always default to Not Restartable. There are three options:

• Not Restartable (default) — the gate's approval decision is final and cannot be reopened.

• Project Managers — users with project management permissions can restart the gate.

• Project Administrators Only — only project administrators can restart the gate.

A gate can only be restarted if it belongs to the project's current phase. Gates in past phases (already progressed through) cannot be restarted, even if the restart policy and user permissions would otherwise allow it. This ensures that restarting a gate is only used to revisit a decision that is relevant to where the project currently stands, preventing unintended changes to completed phases or phases the project hasn't reached yet.

Restarting a gate reopens it, makes it blocking again, and resets the approval flow based on the gate type. For decision-based approval gates, the existing request is reset so the same approvers can make a fresh decision. For workflow-based approval gates, the action card is moved back to the first column so it can progress through the workflow again, while preserving the previous decision history for reference.

There is no limit on how many times a gate can be restarted — each time the gate is subsequently closed (approved or rejected), it can be restarted again provided the user has the required permissions and the gate remains in the current phase.

The restart policy is configured per gate, allowing different levels of control across gates within the same phase or methodology. If a gate's mode is later changed away from Approval, the restart policy is automatically reset to Not Restartable.

You can read more about restarting stage gates here.

When a workflow-based stage gate is restarted, any documents already synced to the project remain in place. If the approval action is updated with revised documents and submitted again, Fluid compares the new submission with the existing project documents, archives the previous versions, and adds the latest versions to the active project folder.

This gives PMOs and project managers a clear audit trail of what was approved at each stage, while keeping the current approved version easy to find. If document protection is enabled, both the synced project documents and the source documents on the workflow action are protected as part of the approval process.

For more detail, see the Knowledge Base article on documents in workflow-based stage gates.

You can now configure Informational stage gates for scenarios where you want to show relevant information without blocking project progress.

Informational gates are non-blocking and are always treated as closed in Fluid. Unlike Declared gates, which are manually closed, or Approval gates, which require sign-off, Informational gates do not require a gate action in the system before the project can move forward.

They can be used to surface useful context at a specific point in the project lifecycle, such as guidance, supporting information, or a link to an external report, dashboard, document, or workflow.

Informational gates also support a Hyperlink Expression, allowing you to generate dynamic project-specific links using field values such as [Id] or [ExternalReference] or custom property values. This means you can direct your team straight to a filtered BI report, a SharePoint page, or any other external system relevant to the project — without anyone needing to look up the URL themselves.

You can read more about Informational stage gates here.

You can now use External Workflow as a new stage gate type for projects where the gate state is managed by an external app or workflow, rather than by users in Fluid.

This gate is designed for integration-led governance scenarios. Instead of being closed manually by Project Managers, the gate is updated by an external system — such as Power Automate, Power Apps, ServiceNow, Jira, or Azure DevOps — which writes the gate status back to Fluid via the Fluid V3 API.

When added to a phase, the gate is visible in the workspace so users can see whether it is open, in progress, or closed, but they cannot close it themselves. The external app remains the source of the gate decision, while Fluid reflects the current status on the project.

You can also configure a dynamic hyperlink on the gate to direct users straight to the external workflow, form, or approval tool that manages the action.

As with other gates, if Enabled Blocking Phase Stage Gates is turned on, the phase cannot progress until the gate is closed — in this case, by the connected external system.

External Workflow gates can optionally be paired with a Fluid approval. When an Approval Type is configured on the gate (such as Named, Executive, Business Owner, Owner, or Portfolio Approver), the external system's close request does not close the gate immediately. Instead, Fluid creates a formal approval task for the configured approver. The gate remains blocked until the approver signs off — giving you a two-step governance model where the external system triggers the review and a Fluid approver makes the final decision.

This new gate type gives teams a cleaner way to support governance processes that happen outside Fluid, while still keeping gate visibility and project control inside Fluid. It is especially useful when manual override should not be allowed.

Read the full user guide here.

Read the full user guide for External Workflow Gates and External Workflow Gates Paired with Approvals.

We’ve added two new governance checks to help PMOs identify projects where schedules or impacts may not be receiving regular review. By flagging projects where key data has not been updated within a defined timeframe, these checks make it easier to prompt timely action from project managers.

Schedule Recently Updated
This check looks at whether any schedule item has been updated within a timeframe you define. If no updates have been made during that period, the project is flagged for attention.

Keeping schedules up to date is a core responsibility for project managers. This check gives PMOs a simple way to spot projects where schedule data may no longer reflect the latest plan and where follow-up may be needed.

Impacts Recently Updated
This check looks at whether any open impact has been updated within your chosen timeframe. If open impacts have not been reviewed recently, the project is flagged for attention.

Project managers need to regularly review impacts to ensure risks and consequences are still accurate. This check helps PMOs identify where impact data may be out of date, so they can prompt timely review before issues are missed.

• Expressions – Financial Top Line Data: Financial top-line data is now available within the expression context for Stage Gates and Governance Assessments. This allows expressions to incorporate key financial metrics when determining applicability or outcomes, enabling more financially driven governance rules and decision-making.

• Stage Gates – Bulk Edit: Stage gates can now be updated using bulk edit, making it easier to apply changes across multiple records more efficiently. You can read more about the new functionality here.

• Project Audit History: The Project Audit History page now includes a dedicated section for project approvals. This section lists approvals associated with the project together with key details such as approval date, approver, workflow state, and any comments entered on the decision.

When teams need to deliver work in defined stages—such as releases, work packages, or phased delivery—sub-projects often need to follow a consistent structure. This update gives you more control over how those sub-projects are created, helping ensure each one is set up in the right place, with the right information, at the right point in your workflow.

With Project Workflow on a Project Pipeline board, you can now configure a column to automatically create a sub-project when a card is moved into it. This is especially useful for Agile delivery teams managing multiple releases from a parent project, where each release needs its own child project for planning, tracking, and reporting. Instead of creating release projects manually, teams can use the workflow to create them in a more consistent and governed way.

When a card reaches a configured Create Project column, Fluid creates a new sub-project beneath the linked parent project. The new sub-project uses the card title as its name and carries over matching card properties, attached documents, and relevant project details. If later columns are set to sync, the same card can continue updating the existing sub-project as it progresses through the workflow.

For step-by-step setup guidance and configuration details, see the full help article.

You can now make project workflows visible to non-project admins when they are explicitly included in a workflow’s Limited Work Request list. This means users who are authorised to trigger specific project-level workflows — such as updating project data or creating subprojects — no longer need project admin rights just to see and launch them. The change removes an unnecessary restriction and makes it easier for the right people to run the workflows they’ve been assigned.

Project Workflow now supports syncing first-class properties even after a project has been created. Previously, matching properties were only copied from the workflow card to the project at the moment of project creation. Now, if a workflow stage includes sync properties on a column, the corresponding card property will continue to sync to the matching project property later in the workflow as well. This makes it easier to keep project data aligned as it evolves, rather than relying only on the initial creation step.

To make workflow requests easier to recognise and manage, any request triggered from a project — whether from a stage gate or a project workflow — will now automatically display the relevant project reference on the card. The same reference will also be added to any decision associated with that workflow.

Previously, workflow requests and related decisions only displayed the project title. While this helps, it is not always the identifier PMOs, portfolio managers, and approvers rely on when reviewing projects across a portfolio. Even when a project is created directly in Fluid through Project Intake, the project reference often becomes the key identifier used in day-to-day governance. In some cases, teams also maintain an external reference to link Fluid with other business systems or downstream processes. Showing the relevant reference directly on workflow requests and decisions makes it easier to recognise the right project at a glance, reduce ambiguity during review, and support faster, more confident approvals.

By default, the displayed reference follows this order: Alternate Reference, then External Reference, then Project ID.

Workflow request decisions now show the date they were approved or rejected directly in the decision card. Before, only the status was visible, which made it harder to understand exactly when a decision had been made.

By surfacing the decision date, teams get a clearer audit trail, better historical context, and an easier way to track request progress and governance activity at a glance.

You can now protect key schedule items so they cannot be renamed, retyped, or deleted by non-admin users.

This is especially valuable when building project templates, where standard phases, milestones, deliverables, and governance checkpoints need to be included in every project created from that template. By setting these items as protected up front, PMOs and Project Administrators can make sure important schedule structure stays in place as Project Managers tailor the rest of the plan.

Once Enable Protected Schedule Items is turned on in Feature Settings, Project Administrators can mark schedule items as protected. This can be done directly in the schedule or through bulk edit and template imports using the Protected column.

When an item is protected, non-admin users cannot:

• change the title

• change the type or subtype

• delete the item

• delete a parent item that contains protected child items

They can still update other scheduling details such as dates, status, assignments, and progress.

This makes it easier to standardise schedule governance across projects without making the whole plan inflexible.

You can read more about protected schedule items here.

You can now mark schedule items as L5 – Suppressed to remove them from the active plan without deleting them. This is useful for descoped work, deferred phases, or template tasks that should be kept for reference but no longer included in reporting.

When a schedule item is set to L5 – Suppressed, it remains visible in the project Gantt but is treated as inactive. Suppressed items are excluded from portfolio schedules, roadmaps, watchlists, promoted schedule components, status reports, project % complete calculations, and schedule-based governance checks. They also do not trigger overdue or late indicators.

If you suppress a parent item, all child items are suppressed automatically. Reverting the item back to L1–L4 restores it to the active plan.

Users with Manage permission or above can update promotion levels individually or in bulk.

For full details on behaviour, permissions, and recommended use cases, see the KB article on Inactive Schedule Items.

You can now update the promotion level for multiple tasks at once in Edit Gantt View. To use this feature, first select the tasks you want to update — the Change Promotion action becomes available once tasks are selected. You can use Shift to select a continuous range of tasks, or Ctrl/Cmd to select individual tasks.

This makes it easier to quickly adjust promotion levels across a group of tasks, depending on the report you are working on, without having to update each task one by one. As a result, users can make changes faster, work more efficiently through larger sets of tasks, and keep promotion settings aligned more consistently across their plan.

The Enable Project Managers Baseline setting has been updated to give more flexibility over who can create baselines.

When the setting is on, project managers can baseline projects.

Previously, when the setting was off, only project administrators could do this. Now, when the setting is off, portfolio administrators can also create baselines. This expands access for organisations that manage baselining at portfolio level.

We have introduced Strict Risk and Issue Management to help organisations improve the quality, consistency, and usefulness of risk and issue data across the portfolio. In many cases, Risks and Issues are logged with only partial information, which can make ownership unclear, weaken reporting, and make it harder to track mitigation actions effectively. This feature helps address that by requiring users to complete key fields before a Risk or Issue can be saved.

The feature is controlled by the Disable Strict Risk and Issue Reporting feature flag, which can be configured in Administration Console > Setup Project Features. When strict mode is enabled, users must complete all mandatory fields before saving a Risk or Issue. These fields include Description, Impact, Probability, Owner, Due Date, and Mitigation.

Strict validation applies only to Risks and Issues. Other impact types, such as Assumption, Dependencies, Changes or Lessons Learned are not affected.

For full details on how the flag works, including its inverted logic and the impact types affected, see Strict Risk and Issue Management.

In large programmes and portfolios, not every impact (such as risks, issues, dependencies, decisions, and lessons) stays relevant forever. Some may be descoped, resolved outside the formal workflow, or simply logged as placeholders. Previously, these cluttered up workspaces, dashboards, and governance views—affecting metrics and drawing attention away from the items that matter right now.

The L5 – Suppressed promotion level solves this by allowing PMOs and PMs to “retire” impacts gracefully. Suppressed impacts remain in the system for audit trail and future reference, but no longer influence reporting, compliance, or day-to-day project views.

How It Works

• Set as L5 – Suppressed: Any impact (risk, issue, dependency, decision, or lesson) can be set to L5 using the Promotion Level field.

• Hidden from dashboards and portfolio reports: Once suppressed, these impacts are excluded from dashboards, most workspace views, watchlists, and roll-up reports. They will not appear in governance checks or contribute to compliance metrics.

• Reversible: The suppression is not permanent—PMOs and PMs can restore an impact by updating its promotion level back to L1–L4 at any time, returning it to active workflow and visibility.

We’ve introduced Strict Status Reporting to help improve the quality, consistency, and control of project status reporting.

When this feature is enabled, Project Managers can only update status reports dated today or in the future, helping prevent retrospective changes to previously submitted reporting periods. It also makes key fields on the status report mandatory, including Strapline, Achievements, and Next Steps, so reports contain the minimum information needed for effective review and oversight.

Project Administrators can still edit past-dated reports where needed. The same rules also apply to bulk update, so bulk edit cannot be used to bypass reporting controls.

This feature is off by default and can be enabled from Administration → Setup Project Features under the Project Health group by Project Administrators.

Click here to read more about strict status reporting.

We’ve introduced Allow Draft Status Reports to give Project Managers more control over when status reports are shared.

When this feature is enabled, users can now choose whether to Save As Draft or Save And Publish when creating a status report. Draft reports remain work in progress and stay hidden from dashboards, portfolio views, and other published reporting outputs until they are explicitly published.

If a draft report exists, the Status Report section in the project workspace displays a yellow banner. Users can select Edit Draft Report from this banner to reopen the draft, continue working on it, or delete it if no longer needed.

Once published, the report becomes visible as part of formal reporting. If your organisation also uses Strict Status Reporting, edit access after publishing will follow those rules.

Bulk Edit has also been updated. When the feature is enabled, a new PublishedStatus column is available, allowing Project Managers to view and update whether a report is set to Draft or Published.

This feature is off by default and Project Administrators can enable it from Administration → Setup Project Features under the Project Health group.

To read more about draft status reports, click here.

Project Administrators can now configure the Executive Summary field on status reports in two new ways:

• Rename the Executive Summary field: using Project Labels & Field Names, administrators can change the field label to match their organisation’s terminology.

• Show or hide the Executive Summary field: using the Enable Status Report Executive Summary feature flag, administrators can control whether the field is available across status reports, dashboards, and exports. When disabled, the field is hidden from the UI, excluded from Excel exports, and ignored by the Excel loader if the column is present.

This gives teams more flexibility to align status reporting with their internal language and reporting needs. For full configuration details, see Configure the Strapline and Executive Summary on Status Reports.

You can now mark projects as Confidential to limit visibility and access to only the users explicitly named on the project.

When a project is marked as confidential, access granted through broad global roles is removed and the project is hidden from places such as search, portfolio dashboards, and programme hierarchies. This means users with roles such as Project Viewer or Portfolio Administrator cannot see or access confidential projects unless they have been explicitly added to the project.

The Confidential setting can only be enabled or updated by users with the Project Administrator role, either in the project settings or through Bulk Edit. Project Administrators continue to have access to confidential projects so they can manage the setting when needed.

Confidential Projects give you tighter control over sensitive initiatives, helping ensure that only the right people can view and manage them.

For full details on how confidential projects work, see the Confidential Projects knowledge base article.

• Document Export to Excel: Document exports now include an option to export active and archived documents or active documentsonly.

• PDF Export: Custom property sections are now expanded by default when using PDF export, ensuring all grouped properties are visible without appearing collapsed in the output.

• Home Page: The home page layout has been updated to make key user actions more prominent. Timesheets and Requests now appear in the top-left area of the page, bringing the most action-oriented tasks into immediate view as soon as users land on the home page.