Baselines
Configuration Setting
The configuration setting relating to Project Baselines can be found under the Projects heading and is called Baseline Settings (baselineSettings).
The Project Baseline Settings configuration setting consists of the following properties:
| Property Name | Description |
|---|---|
| Enable Project Baselining | This property determines whether the Baselining feature is turned on within Altus. The default value is 'Yes' (true). If switched to 'No' then the Baselines functionality will not display within Altus. |
| Security Roles who can set Baselines in Altus | This property allows you to define which security roles are able to create Baselines. Users who have been granted one of these roles (either directly or through Team membership) will be able to create a Baseline. Please note, if adding new security roles to this setting, please ensure that the Security Role itself contains appropriate permissions to any Baseline related Entities/Tables. |
Limitations
Baselines per Project
There is a limited number of baselines per Project. Once the limit has been reached, users will be prevented from creating more Baselines for that Project. To create a new Baseline for a Project once the limit has been reached, delete one of the previously created Baselines for that Project.
See Baseline Limits for more details
Mappings
By default, all out of the box Altus fields at the Project and Task level are copied/captured during the Baselining process.
Custom fields can be included in the Baselining process simply by creating a field in the related Baseline table with the same internal name as the corresponding custom field in the Project or Task table. Ideally the field type should also match (however, conversion attempts will be made if the fields do not match).
For example, consider a custom field on the Project table called 'Detailed Description' which has an internal name of cr4be_DetailedDescription and which is a Multiple lines of text field. To include this custom field in the Baselining process, navigate to the Project Baseline table and create a new field in that table with the following details:
| Display Name | (Internal) Name | Field Type |
|---|---|---|
| Detailed Description | cr4be_DetailedDescription [Note: If you are for some reason unable to create the field in this table with the same publisher prefix as the custom field in the Project table, go ahead and create the field with a different publisher prefix, just ensure that the field name after the prefix is identical to the Project custom field. e.g. c6efa_DetailedDescription would also be sufficient) | Multiple lines of text |
Once the field is created on the Project Baseline table, the next time a Baseline is created for a Project, the custom field value should be successfully copied into the new field in the Project Baseline table.
Tables/Entities
Baseline
The Baseline table is used to store key information about each Baseline that has been created.
It includes the following fields:
| Display Name | Field Type | Description |
|---|---|---|
| Name | Single line of text | The Name of the Baseline. |
| Description | Multiple lines of text | Description of the Baseline. |
| Project | Lookup (Project) | This field contains a lookup reference to the Project that the baseline has been created for. |
| Collection Status | Multiple lines of text | Contains a log of output from the Baseline creation process. |
| Is Complete | Yes/No | Indicates whether the Baseline has been completed (e.g. will switch to Yes when all Baseline data has been copied successfully). |
| Is Reportable | Yes/No | Indicates whether this is the Reportable Baseline for a Project. Each Project can have only one baseline marked as Is Reportable. |
| Approval Status | Choice | Field that can be used for extending the behaviour of Baselines to include an approval mechanism. |
The following fields store a copy of the Project's corresponding field value as at the time the Baseline is created. These fields are automatically populated using the Relationship Mappings feature in Dynamics/Dataverse.
| Display Name | Field Type |
|---|---|
| Duration Weekdays (Days) | Whole number |
| Effort (Hours) | Decimal |
| Finish | Date only (Date only) |
| Start | Date only (Date only) |
Additional fields could be added (as required) to utilise the above behaviour by;
- Creating a new field on the Baseline table (to store the data) - ensure you match the field type with the source field on the Project table
- Open the Relationship between the Baseline table and the Project table in the classic editor and select to view Mappings. Add a mapping from the Project field to the new Baseline field.
- Optionally add the new Baseline field to the Baseline forms (Quick Create and/or Information) to expose the field value in the UI
Project Baseline
The Project Baseline table has been set up to store a copy of values relating to the Project that has been referenced in the Baseline. When the Baseline has been created, the Baseline server-side process will attempt to take a copy of all values currently stored in the Project table for that Project and store a copy of those values in the Project Baseline table.
Fields have been created in the Project Baseline table for each out of the box Project fields (and when the Baseline is created, fields will automatically be mapped based on the internal field names). The following fields are mapped (internal to the Baseline process) as exceptions - primarily because the field types are specific to Baselines, or are 'internal' to Dataverse and using those fields directly on the Project Baseline table did not make sense:
| Project Field Display Name (Internal Name) | Field Type | Project Baseline Field Display Name (Internal Name) | Field Type |
|---|---|---|---|
| Sensei Project (sensei_projectId) | Unique identifier | Project Id (sensei_projectId) | Single line of text |
| Status (statecode) | Choice | Project Status (sensei_projectstatecode) | Single line of text |
| Status Reason (statuscode) | Choice | Project Status Reason (sensei_projectstatuscode) | Single line of text |
| Modified On (modifiedon) | Date and Time | Project Modified On (sensei_projectmodifiedon) | Date and time |
| Modified By (modifiedby) | Lookup (User) | Project Modified By (sensei_projectmodifiedby) | Lookup (User) |
In addition, the Baseline field (sensei_baseline) will be populated with a lookup reference to the related Baseline for this Project Baseline record.
The following fields are automatically ignored during the Baseline processing for all tables relating to baselines (e.g. Projects and Tasks), because they are fields internal to Dataverse and are not relevant to Baseline data:
- createdby
- createdonbehalfby
- createdon
- importsequencenumber
- modifiedonbehalfby
- owningbusinessunit
- owninguser
- overriddencreatedon
- versionnumber
Project Task Baseline
The Project Task Baseline table has been set up to store a copy of values relating to the Tasks associated to the Project that is referenced in the Baseline. When the Baseline has been created, the Baseline server-side process will attempt to take a copy of all values currently stored in the Task table for that Project and store a copy of those values in the Project Task Baseline table.
Fields have been created in the Task Baseline table for each out of the box Project Task field (and when the Baseline is created, fields will automatically be mapped based on the internal field names). The following fields are mapped (internal to the Baseline process) as exceptions - primarily because the field types are specific to Baselines, or are 'internal' to Dataverse and using those fields directly on the Task Baseline table did not make sense:
| Project Task Field Display Name (Internal Name) | Field Type | Project Task Baseline Field Display Name (Internal Name) | Field Type |
|---|---|---|---|
| Sensei Task (sensei_taskId) | Unique identifier | Task Id (sensei_taskId) | Single line of text |
| Status (statecode) | Choice | Task Status (sensei_taskstatecode) | Single line of text |
| Status Reason (statuscode) | Choice | Task Status Reason (sensei_taskstatuscode) | Single line of text |
| Modified On (modifiedon) | Date and Time | Task Modified On (sensei_projectmodifiedon) | Date and time |
| Modified By (modifiedby) | Lookup (User) | Task Modified By (sensei_projectmodifiedby) | Lookup (User) |
In addition, the Baseline field (sensei_baseline) will be populated with a lookup reference to the related Baseline for this Project Task Baseline record.
Reportable Baseline
The 'Is Reportable' flag field in the Baseline table indicates for each Baseline whether it is the 'Reportable Baseline' for a Project. Each Project can have a maximum of 1 complete Reportable Baseline at any time.
If a Reportable Baseline exists for a Project and a new Baseline is created where it is marked as Reportable, then the Baseline process will remove the 'Is Reportable' flag from the previous Reportable Baseline (leaving the new Baseline as the Reportable Baseline for that Project).
Project Table Baseline Fields
One additional function performed by the server-side Baseline behaviour is to populate a series of Baseline-related fields directly on the Project table for the related Project. These values store values from the Baseline information directly on the Project record, and are exposed on the Project form and in the 'All Active Projects - Baselines' View.
These fields are;
- Baselined
- Baseline Created By
- Baseline Created On
- Baseline Duration Weekdays (Days)
- Baseline Effort (Hours)
- Baseline Finish
- Baseline Start
The presence of values in these fields also contributes to the following calculated fields;
- Effort Variance (Hours)
- Finish Variance (Days)
Business Rule
If the 'Baselined' (sensei_isbaselined) field on the Project record contains a Yes/true value (e.g. a Reportable Baseline exists for that Project), then the Project form Details tab will display the related Baseline field values. These fields will hide automatically if no Reportable Baseline exists for the Project.
This is controlled by the Hide baseline fields when not populated Business Rule on the Project table.
Baselines and Status Updates
A previously existing feature in Altus allowed configuration of Baseline functionality for Status Updates. More information on this feature is available here.
The Status Update Baseline feature is still available to be used and if enabled, will continue to work on the Status Update form - and the values for baseline finish and work on the Status Update screen will be set from Status Updates. If the Status Update Baseline feature is disabled and Project Baselines are enabled, then the source for baseline finish and work on the Status Update form will be set from the Reportable Baseline for the Project.
Extending the Baseline Behaviour
Creating Baselines Programatically
Baselines can be created programmatically by utilising any of the tools Microsoft makes available for Dataverse record creation (e.g. Rest API calls, Flows, etc).
If you choose to create Baseline records programmatically, please ensure that your business logic:
- populates the Project Lookup field on the Baseline record at creation time (to ensure that the background process is triggered correctly)
- explicitly populates values for Start, Finish, Effort (Hours) and Duration Weekdays (Days) on the Baseline record, based on the current Project data. When created via a Dataverse form, if the Project lookup is populated, these values will automatically be mapped across. This behaviour is not present when creating Baseline records via other means.
- ensure that the limit of 20 Baselines per Project is adhered to (this is not currently be enforced server side)
Baseline Approval Workflow implementation
Baseline Approvals have not been implemented out of the box as part of the Baseline feature in Altus - however the feature has been designed in such a way that Baseline Approvals can be customised and implemented as desired.
A field called Approval Status exists by default on the Baseline table. The field will default to an empty value, but it is a Choice field preconfigured to allow values of 'Pending', 'Approved' and 'Rejected'.
If you wish to implement custom Baseline Approval functionality, you may wish to consider:
- Adding a Flow or other event based process that is triggered by creation of a Baseline record (you may wish to wait for the Is Complete flag to be set to true to ensure that the Baseline data has been successfully copied and to ensure your updates do not clash with any performed by the Baseline creation process).
- Set the Approval Status field for the Baseline record to 'Pending'
- If the Baseline being approved is a Reportable Baseline, consider whether you wish to temporarily revert a previous Reportable Baseline (which would have been marked by the Baseline creation process as no longer Reportable) to be the Reportable Baseline again while the approval takes place.
- Add whatever approval logic you wish, ensuring that you update the Approval Status field on approval or rejection.
- If you modified the Reportable Baseline toggle for the Baseline while it was being approved, ensure that you toggle it back on after Approval.
In order to control the list of Baselines that display in the drop down Baselines button in the Tasks ribbon, you can modify the Filter on the 'Active Baselines' View - and could add a filter to ensure that only Baselines with a value of 'Approved' are shown.
Reporting
Currently Altus out of the box reports do not currently expose any of the Baseline data. However, existing reports can be customised to include this data, or new reports can be created specifically for Baseline data.
See the Tables/Entities section of this documentation for more information on the data structure.
Troubleshooting
Baseline Fields visible for Projects even after Baseline feature is turned off
If Baseline feature has been turned on and Baselines have been successfully created, then that Baseline data will continue to exist in the environment even if the Baseline feature is later turned off.
Consequently legacy Baseline data would still surface in the 'All Active Projects - Baselines' View and when viewing a Project where a Reportable Baseline exists, then the Baseline fields would still be visible on the Details tab (via the Business Rule). Any Reports which were customised to expose Baseline data would also still continue to display that data.
Baseline fails to complete
When a new Baseline record is created, a background Plugin function (Sensei_ProcessBaseline) in the SenseiDataIngestionPlugin assembly is triggered. This Plugin handles the copying of relevant data to the Project Baseline and Project Task Baseline tables and then marks the Baseline Is Complete field as complete. If a Baseline has been created, but is still displaying with a spinner icon and greyed-out in the user interface for more than three minutes, then it is likely that something has prevented the function from completing. This scenario will be highlighted with a failure warning icon next to a failed Baseline.
To troubleshoot an incomplete Baseline, start by looking at the logs recorded in the Collection Status field on the Baseline record. This can be exposed either through an API call or by adding that column to the Baseline data table in make.powerapps.com. If those logs do not prove useful, next take a look for a System Job failure or a Plugin Trace Log run for Sensei_ProcessBaseline from around the time that the Baseline record was first created.
Please note that the Plugin function must be able to run in its allocated time of 120 seconds. If a Project has an excessive number of tasks (beyond recommended limits for Altus), the process may fail due to the sheer amount of data being copied.