Governance and enterprise controls

These controls decide who may change a plan, who sees what, who gets in and what is kept. They belong to organizations, so they live on the organization page and in the plan settings of an organization project.

A change request asks a second person to authorize a change. Approving it applies the change to the plan as the approver, and the plan history names both people. Nobody can decide their own request: the rule is enforced by the database, not only by the screens.

There are two kinds:

• Plan changes. Someone who may not make a change – a contributor who cannot edit the schedule, for example – tries it in the plan. The banner that says it was refused offers Send as a change request. The request carries the exact operations and a plain-language summary of them. If an item was deleted in the meantime, approving marks the request as approved but not applied and says why.
• Baseline changes. When a project manager turns on Replacing or clearing a baseline needs approval in the Approvals view, saving into a baseline slot that already holds one, and clearing a slot, need a second person. Saving into an empty slot stays free.

Approvers are organization admins, project managers and anyone whose custom role allows approving. Requests are listed in the Approvals view of the plan, and approvers are notified in the inbox.

Requests are available on organization projects only: a personal project has one person.

A custom role is a base role – manager, contributor or viewer – plus three switches:

• Can see costs and rates, which covers the cost columns, the cost report, earned value, the rates and the cost part of exports;
• Can see and edit restricted fields;
• Can approve change requests.

Organization admins define roles on the organization page and project managers assign them in the People section of the plan settings. A role never gives access to a project; it changes what someone who already has access may see and do. A manager can be given a role without cost access, and a viewer can be given cost access.

A custom field marked Restricted is hidden from everyone whose role does not allow restricted fields: its values are not sent to their browser, it does not appear in the list of fields and they cannot write it. When they edit an item, the values they cannot see are kept as they are.

A share link shows a read-only view of a plan without signing in: overall progress, whether the finish is on track against the target, the milestones and the top of the outline. The Roadmap scope adds the second level of the outline with its dates. The view never shows people, comments, descriptions, linked activity or costs.

• A link always expires, after at most 180 days, and can be revoked at any time.
• Only a hash of the link is stored, so the link itself is shown once when you create it.
• A project can have 20 active links. The list shows when each was last opened and how many times.

A guest is a named person: a project manager invites an email address, the person signs in or creates a Flow Relay account with that address and sees the same view. A guest is not a member of the organization, is in no team and cannot open anything else in the project. Guests see the plans shared with them under Shared with you. Access ends at the expiry date or when a manager removes the guest.

Single sign-on lets people sign in through the identity provider of their company (SAML 2.0).

1. On the organization page, under Single sign-on and provisioning, add your email domain. Flow Relay shows a TXT record with a name and a value.
2. Add the record to the DNS of the domain and choose Check the record. A verified domain belongs to one organization only.
3. Contact support@flowrelay.it to register your identity provider for the domain. Flow Relay support does this with your metadata, and it is the only step that cannot be done on the page.
4. Turn on Single sign-on is set up for this domain. People with an address on the domain can now use Sign in with single sign-on on the login page.
5. Sign in through single sign-on yourself. Only then can you turn on Require it: from that moment passwords, magic links and passkeys stop working for addresses on the domain and existing sessions that did not use single sign-on are ended. Turning it on without proof that single sign-on works could lock everybody out, so the page refuses.

Turning Require it off is always possible.

SCIM 2.0 lets your identity provider (Okta, Microsoft Entra ID, OneLogin and others) add, update and deactivate members and teams by itself.

Create a token under SCIM provisioning on the organization page and give the identity provider the base URL shown there and the token as a bearer token. A token belongs to one organization, is shown once and can be revoked.

The last administrator of an organization cannot be deactivated. The email address of an account cannot be changed through SCIM, and names are not overwritten after the account exists. The supported filters are userName eq, externalId eq and id eq for users and displayName eq and id eq for groups; the discovery endpoints (ServiceProviderConfig, ResourceTypes, Schemas) are served too.

Every change to a plan is recorded: who made it, when and which fields changed. The history is read per item or per project and can never be filtered by person.

Organization admins manage it under Change history on the organization page:

• Retention. The default is 24 months. Enterprise organizations can choose from 6 to 120 months. After that the entries are deleted.
• Legal hold. Turning it on needs a written reason. While it is on nothing is deleted – not by the retention job, not when a project is deleted – and the organization itself cannot be deleted. Release the hold to delete again.
• Export. Download the history of a period, up to one year and 50,000 rows at a time, as CSV or JSON lines. The columns are the id, the time, the organization, the project, the type and id of the entity, the action, the actor and its kind, the batch and the changes. The export cannot be filtered by person, and each export is itself written to the history.

Turning a legal hold on or off, exporting the history and changing single sign-on, provisioning or roles are recorded in the history as well.