The Suivi Portal is a structured and secure space that allows you to centralize, organize, and share board views and content, while precisely controlling access rights by business role.

It becomes the single entry point to provide everyone with the right information, at the right level, at the right time.

Portal objectives

• Centralize the big picture and key information in a single space.

• Structure navigation to make content clear, readable and easy to access.

• Precisely control access through business roles and page-level permissions.

General Portal Operation

The portal consists of the following elements:

1. an optional home page composed of one or more tabs (called Space), each containing different widgets,

2. page sections

3. pages that can be board views or editorial content pages.

In this portal, you can create business roles (4) tailored to the specific needs of your project. Each role has customizable permissions for each page of the site.

During the design phase, the portal remains inaccessible to users. It becomes available when the administrator chooses to start it. From that moment on, the portal becomes public:

• either for its members strictly with varying levels of content access based on business roles,

• or for all members of the organization.

Managing roles & permissions in the portal

Roles and permissions in the portal allow you to define access and action authorizations on portal pages. There are two types of roles: system roles and business roles.

System roles

A system role is a role that allows working on portal design, defining roles & permissions, and inviting members who can access it. The permissions of these roles are not customizable. Each member can only have one system role. However, a system role is not mandatory for all members.

Among system roles, we distinguish:

• Administrator: they are the super user dedicated to portal design. They create the portal layout by inserting shared views, configure it (color, logo, etc.), participate in writing the content of the home page and editorial pages, define business roles and permissions on each page, and invite members. They are the only one who can stop or start the portal. Note that the Administrator role does not automatically grant administration rights on the content of views that are exposed in the portal. The administrator will only have viewing rights for views unless they have specific rights in the corresponding board. Furthermore, for a view to be added, two conditions are mandatory:
  • The view must be shared,

  • The administrator must also be a member of the board to which the view belongs.

• Client administrator: this role allows the person in charge of the portal on the client side to invite members and assign them business roles only (not system roles). They do not participate in the portal design itself but can modify the permissions of business roles.

• Contributor: along with the administrator, they participate in designing the portal layout and the editorial content of pages. However, they do not have the right to invite members or define permissions on portal pages for business roles. Their role is therefore limited to designing the portal content. Like the administrator, their contributor role in the portal will only give them viewing rights on views added to the portal unless they have specific rights in the corresponding board.

• Visitor: the system visitor can see the portal before it is started. This role is particularly useful for inviting members to validate the portal content before launch.

Important

System roles strictly grant rights in portal design, via the portal editor, to members. However, they do not automatically assign the same role in the content of view-type pages except for viewing them. For members with system roles to be able to act on the portal's view content, it is necessary that:

• either they have a business role granting them this permission,

• or they are already a member with a corresponding role in the board of the exposed view.

Key takeaways

• The system role allows participation strictly in portal design within the portal editor.

• The system role must be supplemented with a business role or a role in the board of a view for a member with a system role to be able to act on it (otherwise, they can only view it).

• The system role can access the portal in edit mode or the started portal. However, any modification to the portal (excluding the content of its views) is done strictly in the portal in edit mode.

Business roles & permissions

In the portal, business roles are customizable based on the specific needs of the project and are defined by the administrator. Each role has an assigned permission for each page of the portal. Members can hold multiple business roles.

Four permission levels can be applied per role to a portal page:

• Hidden: the page is invisible to members of the business role.

• View: the page is visible, but without the ability to take action on it.

• Comment: the page is visible and allows commenting on elements when it is a view type page.

• Updates: the page is visible and allows modification and/or comments on elements of a view type page. Editorial pages can also be modified (except the home page).

• Contributes: the page is visible and allows adding, modifying and/or commenting on elements of a view type page. This permission also includes modification of editorial pages (except the home page).

Permissions can be applied:

• on the home page,

• on an entire section,

• or on each page individually.

Also note that a utility (tab Permissions by member) allows you to identify the permissions on each page of the portal, for a member or a team, which could potentially be altered by their roles in the boards of the views added to the portal or their system role.

Important

It is not possible to apply a permission to a section while defining an exception for a specific page. Either the permission applies to all pages in the section, or it is defined page by page.

Therefore:

• when the permission is applied to a section, any new page added will automatically have the same permission as the other pages in the section.

• when the permission is defined page by page, any new page added is, by default, set to the Hidden permission. The permission must therefore be manually modified by the designer

When a member has multiple roles (business, system and/or board-related), the applied permission will be the highest among those assigned by their roles. Therefore, a member's actual permission may differ from what is indicated in the permissions matrix by role, as it can be influenced by their system role or their rights in the board.

Quick Start

Creating a portal

Adding and Removing Sections and Pages

Adding a Section, a Page

Step 1: Verify that views are shared in your boards

Step 2: Add all sections and views to be presented to the portal's end users

Delete a view

Creating a role

Assigning one or more business roles during invitation

You can define a permission when inviting a new user:

Assigning new roles to a user

Publishing and sharing the portal

Publishing the portal

When the portal is ready to be published, the administrator can start it (as a reminder, they are the only one who can do so from the portal editor). By default, the portal publication is configured to be accessible to all members of the organization. However, there is another sharing option that allows restricting access to the published portal to its members only.

In the case where publication is open to all members of the organization, each member will be assigned a Visitor role by default, allowing them to view the portal pages. Note, however, that a member may have more permissive rights on certain portal views if they have a stronger role than Visitor in the board for those views. Again, a member will always have the strongest permissions granted by their different roles in Suivi.

Usage recommendations

Members who only have a business role can only access the published portal. For this reason, we recommend inviting these members only once the portal has been started (since an email notification is sent upon invitation, this will prevent them from being offered access that is denied as long as the portal is not started).

Home page specifics (Draft)

The portal home page is composed of one or more spaces, which allow organizing different content distributed across tabs (1 tab = 1 space). When creating the portal, the first space on the home page is automatically set to Draft mode (orange Draft badge). It is essential to understand this concept well and distinguish it from permissions.

Draft mode indicates that the space content is being written and remains inaccessible in the portal even when started until it is finalized. This concept applies at the space level:

• If all spaces on the home page are in Draft, the entire home page is considered to be in Draft.

• As soon as at least one space is no longer in Draft, the home page becomes visible and subject to the permissions that have been granted to it by role.

Key Points

• A home page is only finalized if at least one of its spaces is no longer in Draft mode.

• A finalized home page is only visible to members whose business role has the View permission on the page (system roles always see it).

• Draft mode on the home page blocks its visibility in the portal regardless of the visibility permissions it carries.

Draft mode is currently only available for the home page.