Use of models
Introduction
What is “Use of models”?
Models are reusable templates that define a project’s default structure and behavior—such as which tabs, canvasses, and Kanban lists are available and whether project managers may override them. New projects copy model settings on start; if managers aren’t allowed to change these settings, later changes to the model are automatically applied to all projects based on it.
Who uses it?
PMO/model owners, administrators, and portfolio owners who standardize how projects are created and governed across the organization.
What value does it deliver?
Consistent project setup, faster onboarding, and controlled flexibility (you decide where divergence is allowed). Distinctions between classic and standard project models ensure users see only relevant models when creating projects, improving selection and governance.
Related concept — field sync & publication (Portfolio ↔ Project):
Define immediate field synchronization or scheduled publication (via reporting) to control how data flows between a portfolio item and its linked project. It’s recommended to configure field sync in the portfolio model so all portfolios created from that model behave identically.
How do project models work?
When using project models, it is possible to set whether projects continue to follow the project model’s set-up, or whether the project manager has the rights to adjust the project set-up himself. These permissions can be set for tabs, canvasses and Kanban lists.
When a project is started, the project model settings are transferred to the project. When the project manager is not allowed to change the settings of his / her project from the project model, all changes made in the model will automatically be applied to all projects based on that model.
- Go to your OU via Start.
- Select the Models tab. Under the heading Project models you can adjust an existing model or create a new project model.
- Click on the project model to adjust the settings and click on the Project model settings button at the top right of the screen.
A pop-up will then appear in which you can set the rights of the project manager. You can choose to give the project manager rights to adjust the visibility of tabs, edit canvasses and / or edit Kanban lists.
What is the effect on existing projects if the settings are adjusted?
Activating the above settings, where the project manager has rights to adjust the settings in his / her project, will lead to the following behavior:
Project managers can overrule visibility of tabs
If the project manager is given rights to set the visibility of the tabs, the tabs will initially be visible as can be set in the model. The project manager can then switch tabs on or off via the gear icon at the bottom left of the screen.
When the option to set visibility is disabled by the project manager, the projects based on the respective model will start to follow the settings of the model. The visibility of the tabs as set by the project manager will be overwritten.
Project managers can edit canvasses
If the manager is given rights to edit the canvasses himself through the settings, the canvasses will revert to the settings as they were at the start of the project. Then the project manager can, for his / her projects, adjust the settings of the canvasses for the following items:
- The overview tab
- The canvasses of the products in the Project planning tab
- The canvasses for the frames on the kanban board When the option for editing the canvasses is disabled by project managers, for existing project, based on the relevant model, the canvasses will be taken over from the project model and the custom canvasses will no longer be visible by the project manager.
Project managers can edit Kanban lists
If the project manager is given the rights to edit the kanban lists, the next time the kanban tab is opened, you will be asked to place the existing items (again) in one of the columns. Subsequently, adjustments made in the model will no longer affect the existing projects.
When the option for editing the kanban lists by project managers is disabled, the lists as defined in the project model will be applied to all existing projects based on the respective model. Also after this, the project manager will be asked to place the existing items in one of the lists again the first time the kanban tab is accessed.
How do I create project models for standard projects?
- Go to your OU via Start.
- Select the Models tab. Under the heading Project models you can adjust an existing model or create a new project model.
- If you have already made project models for the standard projects, they will first be opened in classic mode. Via the mode switcher you can convert the project model to a project model for standard projects. After you switch the project model, the model appears in the correct list and opens in the new Project app by default.
When you start a project, only the relevant models come up. A distinction is made between classic project models and standard project models.
You can create a new project in the Project app:
- Go to the Project app and choose + Project toevoegencode>.
- Choose to create a classic project or a standard project. Depending on the type of project, you will see the matching project models that you can choose from.
You can also create a new project via a canvas in the Portfolio app:
- Go to the Portfolio app and open a canvas (card) in the Portfolio funnel.
- Click on START EEN PROJECT
- Fill in all the details.
- If you now want to select a project model, you get a choice of all existing project models, split into classic and standard models.
- After creation, the data from the chosen project model is copied (once) to the new project.
Permissions in models
How do I set permissions for tabs in project models?
When using project models, it is possible to set whether projects continue to follow the project model’s set-up, or whether the project manager has the rights to adjust the project set-up himself. For example, you can set whether the project manager can adjust the visibility of tabs or not:
- Check the option Project managers can overrule tab visibility and click Save.
- Project managers can adjust the visibility of tabs via the gear icon at the bottom left of the page.
A pop-up will appear in which the visibility of tabs can be checked and unchecked.
Note: If this setting is unchecked, the project follows the standard layout of the project model.
What is the effect on existing projects if the settings are adjusted?
If the project manager is given rights to set the visibility of the tabs, the tabs will initially be visible as can be set in the model. The project manager can then switch tabs on or off via the gear icon at the bottom left of the screen.
When the option to set visibility is disabled by the project manager, the projects based on the respective model will start to follow the settings of the model. The visibility of the tabs as set by the project manager will be overwritten.
How do I set permissions for canvasses in project models?
When using project models, it is possible to set whether projects continue to follow the project model’s set-up, or whether the project manager has the rights to adjust the project set-up himself. For example, you can set whether the project manager can edit the canvasses or not:
- Check the option Project manager can edit canvasses and click Save.
- Project managers can configure canvasses by clicking the Configure Canvassen button in the dropdown menu at the top right of the screen.
A pop-up will appear in which the canvas configuration and canvas templates can be added. Note: when creating the project, the canvasses of the project model are copied to the project only once.
Note: if this setting is unchecked, the project follows the standard layout of the project model.
What is the effect on existing projects if the settings are adjusted?
If the manager is given rights to edit the canvases himself through the settings, the canvasses will revert to the settings as they were at the start of the project. Then the project manager can, for his / her projects, adjust the settings of the canvasses for the following items:
- The overview tab
- The canvasses of the products in the Project planning tab
- The canvasses for the frames on the kanban board
When the option for editing the canvasses is disabled by project managers, for existing project, based on the relevant model, the canvasses will be taken over from the project model and the custom canvasses will no longer be visible by the project manager.
How do I set permissions for Kanban lists in project models?
When using project models, it is possible to set whether projects continue to follow the project model’s set-up, or whether the project manager has the rights to adjust the project set-up himself. For example, you can set whether the project manager is allowed to edit the kanban lists or not:
- Check the option Project managers can edit kanban lists and click Save.
- Project managers can add and remove lists on the project’s Kanban tab and on a plan item’s detail page. Note: when creating the project, the Kanban lists of the project model are copied to the project only once.
Note: if this setting is unchecked, the project follows the standard layout of the project model.
What is the effect on existing projects if the settings are adjusted?
If the project manager is given the rights to edit the kanban lists, the next time the kanban tab is opened, you will be asked to place the existing items (again) in one of the columns. Subsequently, adjustments made in the model will no longer affect the existing projects.
When the option for editing the kanban lists by project managers is disabled, the lists as defined in the project model will be applied to all existing projects based on the respective model. Also after this, the project manager will be asked to place the existing items in one of the lists again the first time the kanban tab is accessed.
Configure field behavior between Portfolio item and Project
Portfolio Items and Projects
In a portfolio, portfolio items (change items) are created. These can be implemented as projects. Once that happens, there are two objects namely a ‘Portfolio item’ and a ‘Project’. These two are of the same object type namely ‘Project’. Therefore, they have the same fields available. The two objects are interconnected so that data can be exchanged between them. E.g. the value of fields, the overall planning of the project, logbook information or progress information about the execution of the project;
Field Synchronization and Publication
Data exchange takes place between the portfolio item and the project in two ways, namely:
-
Field synchronization: settings how data of the same field is exchanged between portfolio item and its associated project. Once set, each field change is immediately synchronized in the set way.
-
Publication: this is a mechanism to periodically report data from the project to the corresponding portfolio item. Publishing is performed by the project manager. This by pressing a button in the project. This transfers validated data from the project to the portfolio item at the discretion of the project manager. With publication, the portfolio item can be updated with data from fields, the project schedule but also subsets of log items, financial data such as the Forecast and the contribution made so far to a particular objective (Benefit realization). So with field synchronization, information is synchronized immediately when data changes. While at publication data-exchange not immediately takes place, but as soon as the project leader wants it by means of a button press.
In doing so, it is possible for ‘field-sync‘ two sides on data exchange: from portfolio item to projects and vice versa. Whereas publication involves unilateral data exchange: from project to portfolio item
Therefore, when setting up the Fortes Change Cloud, it is important that you consider which fields require data to be exchanged immediately and which fields require it only upon publication. That requires a different field setting: see section on Field Synchronization.
Field synchronization
Synchronization involves whether or not the value of a field in a portfolio item equals the value of that same field in the linked project.
The Fortes Change Cloud includes standard fields (such as name, description, start date, etc.). In addition, your own fields can be added. We call these “Proprietary fields” (or Custom fields). The method of synchronization can be set for both fields. The default fields have a default setting that can only be changed for some fields. Proprietary fields also have a default setting but can all be changed.
Where can field synchronization be set
It is best practice to set the field synchronization in the portfolio model. As a result, field synchronization works identically for all portfolios created with that portfolio model.
The field synchronization can also be set in a portfolio. This overrides the set field synchronizations in the portfolio model for that single portfolio.
Who can set up field synchronization
Adjust field synchronization in the portfolio model:
-
Manager and Supporter: the user who has rights as a manager or supporter on the Organizational Unit in which the portfolio model resides can change the field sync.
-
System Administrator: in addition, the users who have System Administrator rights in the Fortes Change Cloud (FCC) can modify it.
Customize field synchronization in a portfolio:
-
Manger and Supporter: in a portfolio, those with Manager and Supporter rights on that portfolio can modify the field synchronization.
-
System Administrator: in addition, the users who have System Administrator rights in the Fortes Change Cloud (FCC) can modify it.
Method for setting up field synchronization
- Open the portfolio model: the portfolio model are within an Organizational Unit on the ‘Models’ tab.
- In the portfolio model, go to the ‘Reporting’ tab;
- Click the “Change Field Configuration” button: at the top right of the screen
- Choose the appropriate tab: There are two tabs. One tab contains the “Own fields” (custom fields), the other tab contains the System fields (the standard FCC fields).
- Edit: put the tab in edit-mode This by clicking on the icon with the pen.
The following section shows which settings are possible for field synchronization.
! Setting the field synchronization in a portfolio works identically: only you start at step 2.
What field synchronization settings are possible
Own fields can be assigned a category-name. This is useful because in various places in the FCC, fields with the same category name are displayed together. Also in the field synchronization settings, the category name is shown and the fields are sorted accordingly.
The following settings for field synchronization are possible:
- A change to the portfolio item automatically affects the project
The value entered in a field in the portfolio item is copied into the same field in the project. It is not possible with this setting to modify the value of the field in the project: read only.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Modifiable | Customized | Available | Not modifiable | Synchronized |
- A change at the project automatically affects the portfolio item
This one works exactly the opposite way from setting 1. Now the project is leading and the field in the portfolio item follows the value chosen in the project. The field cannot be completed or modified in the portfolio item.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Not modifiable | Synchronized | Available | Modifiable | Customized |
- A field is modifiable at the portfolio item until the project is started. Then a change at the project automatically works its way into the portfolio item
A variation on 1 and 2 is that as long as there is no project yet the value in the portfolio item can be modified but as soon as a project is started at this portfolio item the value can only be modified by the project. Change in value in the project is passed to the portfolio item.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Modifiable before project start | Synchronized after project start | Available | Modifiable | Customized |
- Changes are not synchronized:
This setting is used in conjunction with ‘Publication’. The field in the portfolio item may have a different value than the same field in the project. If this field is included in the (monthly) report, the value in the portfolio item is overwritten as soon as the (monthly) report is published in the project. Values from the model are also taken into account.
Note that if you have this setting for fields that not are included in the (monthly) reporting then the values between the portfolio item and the project may start to differ permanently from each other!
Tip: if you are using publication then it is wise to check in the canvas on the portfolio side that the field is NOT editable.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Modifiable | — | Available | Modifiable | — |
- Field not available in the Portfolio item or project:
Then there is no synchronization or publication A field may only be relevant on one side. Then you can mark this field as unavailable. If you are using canvases then you can already choose to show or not show a field. This setting then does not add much.
In the example below, the field is only available in the portfolio item and not available in the project.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Modifiable | — | Not available | Not modifiable | — |
Adjustments directly in the portfolio: i.e., not in the model
As mentioned, it is recommended to adjust the field synchronization in the portfolio model. Should you have chosen to make the adjustments to a specific portfolio anyway, it works in the same way as described above.
There is one difference: you can return by field to the setting as it is in the portfolio model. This by selecting ‘No local configuration’.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | No local configuration | No local configuration | No local configuration | No local configuration | No local configuration | No local configuration |
Once you save this setting, the text “No local configuration” disappears and the setting of this field as it appears in the portfolio model is displayed.
Publication: from Project to Portfolio item
In addition to field synchronization, data from a project can also be written to a portfolio item through publishing. This requires using the built-in reporting function.
With this method of reporting, only validated information comes from the project to the portfolio: after all, the project manager must deliberately press the “Publish to Portfolio” button.
In the portfolio model, you can set up reports: e.g., a monthly report. On that report you place the fields and components (such as risks, issues, contributions to objectives) that need to be synchronized to the portfolio item through publishing from the project.
| Category | Internal name | Portfolio — Availability | Portfolio — Modifiability | Portfolio — Behavior | Project — Availability | Project — Modifiability | Project — Behavior |
|---|---|---|---|---|---|---|---|
| Fortes | Department | Available | Modifiable before project start | Customized | Available | Modifiable | Customized |
Note: Only the fields included in the report are published to the portfolio item. This also applies to e.g.:
-
Risico’s, issues
-
Planning
-
Data from the financial grid
Good to know
Always the ‘Publish to portfolio’ button available
Once a report request is sent to a project from a portfolio, the button ‘Publish to portfolio” available. After ‘published’ this button disappears until a new report request is sent from the portfolio. If you want to keep this button permanently available so that you don’t have to send a report request every time, then in the ‘Advanced System Settings’ enter the following toggle: Feature.EnableAlwaysPublishToPortfolio à Custom value = true
Only the System Administrator can perform this!
Publish logs, plan items and finances
In reporting from project to portfolio, logit items, plan items and finances can also be published. See other notes made specifically for this purpose.
Best practices
- Design for consistency first; allow overrides only where needed. Keep the “project manager may edit” options for tabs/canvasses/Kanban off by default; enable selectively per model.
- Prefer “standard” project models for new work. Users see a clean split between classic and standard models during creation; pick the family you support going forward.
- Centralize field behavior in the model. Configure field synchronization (and decide what goes by publication) in the portfolio model so all portfolios inherit identical rules.
- Know the impact on existing projects. Changing manager-override settings can re-apply model layouts (tabs/canvasses) or prompt re-placement of cards on Kanban; plan communications accordingly.
- Document model scope & ownership. Name models clearly (what/for whom) and assign an owner to maintain them (version notes, change log). (Process recommendation.)
FAQ
What’s the difference between classic and standard project models?
When creating a project you’ll see both types; each shows only its relevant models. Choose based on your organization’s preferred setup—standard models are the modern default for new projects.
Do model changes propagate to existing projects?
Yes—if project managers are not allowed to adjust those elements locally. In that case, changing the model applies to all projects based on it. If managers are allowed to edit, their local changes take precedence.
Can a project manager override tabs, canvasses, or Kanban lists?
Only if the model enables it. You can allow overriding tab visibility, canvas configuration, and Kanban lists per model.
Where should I configure field behavior between Portfolio item and Project?
In the portfolio model (recommended). You can also adjust it per portfolio, but model-level settings keep behavior consistent tenant-wide.
Field synchronization vs publication—what’s the difference?
- Field synchronization: immediate, two-way rules that keep a field’s value aligned between portfolio item and project.
- Publication: deliberate push from project to portfolio via the Publish to portfolio action (often on a reporting cadence).
What happens to existing projects when I toggle manager override options?
- Tabs: disabling manager override re-applies model tab visibility.
- Canvasses: disabling override restores canvasses from the model; custom canvasses become hidden.
- Kanban lists: enabling override prompts one-time re-placement of items; disabling reapplies lists from the model and again prompts placement.
Need more support?
For step-by-step instructions or troubleshooting, contact your Fortes Change Cloud administrator or consult in-app help.
TODO: translate this document (user-docs/fcc-essentials/use-of-models.mdx).
Source: C:\Users\MilanOzinga\Development\fcc\knowledge-base\docs\user-docs\fcc-essentials\use-of-models.mdx