2026R2.0 - New Features

What's Different:

Administrators can now apply additional visibility and editing permissions to specific views (tabs) on Metric Templates. These permissions restrict PowerSteering users from viewing or editing certain Metric views based on their assigned work item Roles.

While editing a Metric Template, administrators will now notice a "View Permissions" tab.

Note: This tab is only visible while editing Metric Templates. It will not be available while creating them.

This tab contains an "Apply custom permissions by role" checkbox for each of the Metric's views.

Selecting a view's checkbox allows administrators to configure custom permissions by Role for that specific view.

When the Metric is attached to a work item, users assigned to the listed Roles on the work item will inherit the corresponding permissions.

Note: This tab cannot grant any Metric permissions beyond a work item's Project Task permissions. In other words, this tab cannot grant any additional Project Task permissions; it can only limit them.

For example, imagine a work item that does not grant the "Update Metric numbers" Project Task permission to the Contributor Role. If "Contributor" is given the "Edit" permission for a view on the Metric Template's "View Permissions" tab, the Contributor will still not be able to update any numeric values on the Metric when it is attached to that work item.

Instead, imagine that the Contributor Role is granted the "Update Metric numbers" Project Task permission on the work item, but only the "View" permission on the Metric Template's "View Permissions" tab. Any assigned Contributors will be able to access the Metric view, but they will not be able to update any numeric values. Their Project Task permissions on the work item are limited by the Metric Template's "View Permissions" tab.

Note: Metric view permissions do not have any effect on a user's ability to select Beneficiary tags or set the Metric as "Ready for Rollup".

The following Metric view permissions are available for each Role:

• None: Users assigned to the Role can not access the Metric view nor can they see any data entered into it.

• Default: Users assigned to the Role will not have their permissions changed. Their permissions are still determined by the work item's Project Task permissions.

• View: Users assigned to the Role will be able to access the view and see any data entered into it. However, they will not be able to edit any numeric data, Tags, or Custom Fields. Additionally, they will not be able to lock or unlock any parts of the Metric view.

  Note: Users without the "View Metric Values" Project Task permission will not be able to view the work item's Metrics even if granted this permission.

• Edit: Users assigned to the Role will be able to edit data on the Metric view, including numeric data, Tags, and Custom Fields. Additionally, they will be able to lock or unlock any parts of the Metric view.

  Note: Users without permissions to edit or lock/unlock Metric data will not be able to do so even if granted this permission.

Click here for an example of the "View Permissions" tab in action:

Example: Joanna is in charge of a Metric that keeps track of a Project's charitable donations. The Metric contains a view for "Projected Donations" (donations that are committed, but not yet paid) and "Delivered Donations" (donations that have been paid).

Certain employees are responsible for keeping track of donation commitments while others are responsible for keeping track of paid donations. Joanna would like these individuals to use the Metric to track these amounts, but she wants to limit their access so they do not accidentally add projections or deliveries into the wrong view.
To prevent this, she creates a "Projected Donation Manager" Role and a "Delivered Donation Manager" Role. She ensures that both of these Roles have the "Update Metric numbers" Project Task permission on her Project (which, in her PowerSteering environment, belong under "Edit").

While editing the "Project Donations" Metric Template, she uses the "View Permissions" tab to grant special permissions to these Roles. On the "Projected Donations" view, she gives Projected Donation Managers "Edit" permissions while limiting Delivered Donation Managers to "View" permissions.

On the "Delivered Donations" view, she gives Delivered Donation Managers "Edit" permissions while limiting Projected Donation Managers to "View" permissions.

Users assigned to the "Projected Donation Manager" Role on her Project will be able to edit the "Projected Donations" view, but not "Delivered Donations".

Notice that the Edit Table button is only available under the "Projected Donations" tab.
Conversely, users assigned to the "Delivered Donation Manager" Role on her Project will be able to edit the "Delivered Donations" view, but not "Projected Donations".

Notice that the Edit Table button is only available under the "Delivered Donations" tab.

Benefit:

Prior to this release, Metric-based Project Task permissions were applied to every Metric on a work item. This means that a user who was only required to work on a specific Metric would have to be given permission to edit every single one attached to the project. Users would often be able to see and even update Metric data that was ideally meant to remain confidential.

With this update, administrators can now restrict viewing and editing permissions to not only specific Metrics, but specific Metric views as well. This ensures that sensitive Metric information is accessible only to authorized users.

What's Different:

PowerSteering now leverages artificial intelligence (AI) to determine whether users leave meaningful comments on their Metrics. Comments that are not descriptive enough will be not be immediately saved. Instead, the comment author will be prompted to review the comment before saving.

Note: AI-powered features might not always work as expected. See Upland Software's AI disclaimer for information.

Note: The AI validation process only analyzes the text entered in the comment. No other Metric, work item, or system data is accessed during validation. However, reach out to your PowerSteering representative at any time if you would like to disable AI features.

When users leave a comment on a Metric, they will notice that the textbox now asks them to leave a meaningful comment.

After the user selects Add Comment, a large language model (LLM) evaluates its meaningfulness. Comments that are deemed too vague, irrelevant, cryptic, or devoid of information will be flagged. These comments will not be immediately saved and the AI will respond in red text with suggestions on how to revise the comment.

From here, users can either revise their comment or they can select the "I understand this comment may be insufficient and I want to save it anyway" checkbox to save the comment to the Metric as is.

Tip: Administrators can configure Metric Templates to require comments after edits are made. See Basic Info Metric Tab for more information.

Tip: If you find the AI is either too strict or too lenient on Metric comments, contact your PowerSteering representative to adjust it. Also, please feel free to submit any feedback to your PowerSteering representative to help refine the AI model for future use.

Benefit:

Metric comments are meant to provide context and clarity around changes to a Metric, especially when they are required after making updates. When this is the case, users in charge of maintaining Metrics expect comments that contain useful and meaningful information rather than brief or vague responses.

Prior to this release, users could bypass required comments by typing anything into the textbox (a single character, some quick gibberish, etc.) and selecting Add Comment. This is not necessarily done out of laziness;users often might not believe that their changes are impactful enough to require an explanation. In reality, all comments make Metric data easier to understand and reference later on.

This upgrade offers guidance when a comment may not provide enough value while still giving users the flexibility to save their comment as written. It reflects Upland Software's commitment to harnessing the power of AI to enable a more efficient workplace.

What's Different:

The PowerSteering REST API Measure service has been updated with new endpoints for specific Measure instances and Measure values.

Note: A Measure instance occurs when a Measure Template is attached to a work item.

The service now includes the following endpoints for handling Measure instances:

• GET <http://{host}/{context}/rest/measureservice/v1/instance>

  This endpoint retrieves data for a single Measure instance. The following parameter must be added to specify the Measure instance:

  

  • id (required): The 26-digit ID number of the Measure instance.

    Tip: Measure instance ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/instances> endpoint (below) and locating the "id" value.
    It can also be retrieved by navigating to the Measure instance and viewing the first (not last) 26 digit ID number in the URL after "sp=U".
    

  The response will include all "measureInstance" objects. See the "Object types reference" page in the REST API Help for a full list.

• GET <http://{host}/{context}/rest/measureservice/v1/instances>

  This endpoint retrieves a list of Measure instances and their data. The following request parameters can be added to filter the Measures that appear in the response:

  

  • templateId: Filter the Measure instances by the 26-digit ID number of their Measure Templates.

    Tip: Measure Template ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measuretemplates> endpoint. Individual numbers can also be retrieved by navigating to Measure Library, selecting the template, and viewing the 26 digit ID number after "sp=U" in the URL.
    

  • templateName: Filter the Measure instances by their names. Only Measure instances that contain the parameter value within their names will be included.

  • projectId: Filter the Measure instances by the 26-digit ID numbers of the work items they are attached to. Only Measure instances attached to the indicated work items will be included.

  • projectName: Filter the Measure instances by the names of the work items they are attached to. Only Measure instances attached to the indicated work items will be included. Work items must contain the parameter value within their name.

  • start: Indicate how many results should be skipped in the response.

    Example: Entering "start=50" will omit the first 49 Risks that would have been included in the response.

  • count: Indicate how many Metric instances should be included in the response.

    Example: Entering "start=50" will only include the first 50 Measure instances that would have been included in the response.

  The response will include all "measureInstance" objects for each included Measure instance. See the "Object types reference" page in the REST API Help for a full list.

• POST <http://{host}/{context}/rest/measureservice/v1/instance>

  This endpoint can create a new Measure instance on a work item. The request payload must include the following parameters:

  

  • measureTemplateId: The 26-digit ID number of the Measure Template you would like to add to a work item.

    Tip: Measure Template ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measuretemplates> endpoint. Individual numbers can also be retrieved by navigating to Measure Library, selecting the template, and viewing the 26 digit ID number after "sp=U" in the URL.
    

  • projectId: The 26-digit ID number of the work item you would like to attach the Measure to.

  Successful attachments will be indicated in the response.

  

• DELETE <http://{host}/{context}/rest/measureservice/v1/instance>

  This endpoint can delete a Measure instance from a work item.

  Caution: Deleting a Measure instance will also delete all of its values. This cannot be undone.

  The following parameter must be added to specify the Measure instance:

  

  • id (required): The 26-digit ID number of the Measure instance.

    Tip: Measure instance ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/instances> endpoint and locating the "id" value.
    It can also be retrieved by navigating to the Measure instance and viewing the first (not last) 26 digit ID number in the URL after "sp=U".
    

  Successful deletions will be indicated in the response.

  

Additionally, the service now includes the following endpoints for handling Measure values:

• POST <http://{host}/{context}/rest/measureservice/v1/measurevalues>

  This endpoint can add values to a Measure in bulk. The request payload can include the following parameters for each new value:

  

  • date: The date of the value. If this field is not included, the new value will automatically inherit the current date.

  • projectId: The 26-digit ID number of the work item that the Measure instance is attached to. This field is only required if "measureInstanceId" is not provided.

  • measureInstanceId: The 26-digit ID number of the Measure instance. If this field is provided, there is no need to include "projectId" or "measureTemplateId".

    Tip: Measure instance ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/instances> endpoint and locating the "id" value.
    It can also be retrieved by navigating to the Measure instance and viewing the first (not last) 26 digit ID number in the URL after "sp=U".
    

  • measureTemplateId: The 26-digit ID number of the Measure Template used for the Measure instance. This field is only required if "measureInstanceId" is not provided.

    Tip: Measure Template ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measuretemplates> endpoint. Individual numbers can also be retrieved by navigating to Measure Library, selecting the template, and viewing the 26 digit ID number after "sp=U" in the URL.
    

  • value: The value you would like to add to the Measure instance.

  • current: Indicates whether the value will be the current value for the Measure instance. Enter "true" for yes or "false" for no.

  Successful runs will be indicated in the response.

  

• PUT <http://{host}/{context}/rest/measureservice/v1/measurevalues>

  This endpoint updates existing Measure values. The request payload can include the following parameters for each new value:

  

  • id (required): The 26-digit ID number of the Measure value you would like to update.

    Tip: Measure value ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measure/{measureId}/measureValues> endpoint.

  • value (required if "recalc" is set to "false"): The updated value you would like to replace the indicated value with. If "recalc" below is set to "true", this value will be ignored.

  • recalc (required): Indicates whether to calculate a new value for the Measure using a formula included in the Measure Template. Enter "true" for yes or "false" for no.

  Successful runs will be indicated in the response:

  

• DELETE <http://{host}/{context}/rest/measureservice/v1/measurevalues>

  This endpoint deletes all values of a Measure instance. The request payload can include the following parameters:

  

  • projectId: The 26-digit ID number of the work item that the Measure instance is attached to. This field is only required if "measureInstanceId" is not provided.

  • measureInstanceId: The 26-digit ID number of the Measure instance. If this field is provided, there is no need to include "projectId" or "measureTemplateId".

    Tip: Measure instance ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/instances> endpoint and locating the "id" value.
    It can also be retrieved by navigating to the Measure instance and viewing the first (not last) 26 digit ID number in the URL after "sp=U".
    

  • measureTemplateId: The 26-digit ID number of the Measure Template used for the Measure instance. This field is only required if "measureInstanceId" is not provided.

    Tip: Measure Template ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measuretemplates> endpoint. Individual numbers can also be retrieved by navigating to Measure Library, selecting the template, and viewing the 26 digit ID number after "sp=U" in the URL.
    

  Successful deletions will be indicated in the response.

  

• DELETE <http://{host}/{context}/rest/measureservice/v1/measurevalue/{id}>

  This endpoint deletes an individual Measure value. The value to be deleted is indicated by substituting {id} with the Measure value ID number of the value to be deleted.

  Tip: Measure value ID numbers can be retrieved by running the GET <http://{host}/{context}/rest/measureservice/v1/measure/{measureId}/measureValues> endpoint.

  Successful deletions will be indicated in the response.

  

Benefit:

Prior to this release, the REST API Measure service provided limited support for working with Measure instances. Users could not create or delete Measure instances on work items, and Measure instance information could only be retrieved using a Measure Template ID. In addition, these responses contained less information than the new "measureInstance" object type provides. With this upgrade, users can create, retrieve, and delete Measure instances through the REST API and integrate Measure instance data with external tools and workflows.

Additionally, there were not many options for working with specific Measure values. Users could retrieve them using GET endpoints, but there was no way to add them, update them, or delete them. With this upgrade, the REST API can be used to create integrations that allow users to update their Measure values through tools external to PowerSteering.

If you would like some help taking full advantage of PowerSteering's REST API, contact your PowerSteering representative.

The PowerSteering Dashboard has been redesigned with a more modern and responsive interface.

Prior to this release, many parts of the Dashboard reflected the legacy PowerSteering design.

With this update, users can now select Review → Dashboard (New) from the Navigation Menu.

This opens up the new PowerSteering Dashboard that resembles PowerSteering's updated "UI 2.0" design.

Note: Please note that the new Dashboard configuration options have been moved from the top left-hand corner of the page to the top right-hand corner.

Note: The "Portfolio" configuration has not yet been applied to the new Dashboard interface. This will be introduced in a future release, but the original Dashboard interface must be used for Portfolio planning in the meantime.

Additionally, this new Dashboard includes the following new features:

Search for filter values

Prior to this release, users would filter Dashboard items by scrolling through a drop-down menu to select the specific values that they wanted to include.

With this update, users can now search for these values directly within the menu itself.

Users can then select the filter value(s) from the search results and select the Apply button. The Dashboard will only list items with the selected value(s) under the column.

Benefit:

Prior to this upgrade, users would have to scroll through a drop-down menu of potential column values whenever they wished to add a filter. This was a problem because these menus can contain extremely long lists of values, requiring the user to scroll for a long time.

For example, adding a filter to the "Active Gate" column opened up a drop-down menu that contained every Gate from every Process in the PowerSteering environment.

Click thumbnail to play.

Instead of navigating through long lists, users can simply type their desired values directly into the menu, saving time and creating a more seamless Dashboard experience.

Baselines included in Gantt charts

Prior to this release, Dashboard Gantt charts did not display anything for work item Baselines.

The green bar represents the Start and End Dates for the work item.

With this update, the new Dashboard displays a gray line that represents a work item's Baseline, located directly under the line that represents Start and End Dates.

Note: The gray line on the Dashboard Gantt chart represents the work item's main Baseline (known simply as "Baseline"). It will not represent any of the numbered Baselines.

Tip: See Capture a Baseline from the Summary Page or Capture a Baseline from Project Central for more information on multiple Baselines.

Benefit:

A Baseline can be used to measure Project performance by reporting on schedule variance (how far a Project is ahead or behind the original schedule). As the start and end dates of a Project change, the Baseline dates can be referred to in order to see how the current dates differentiate from the original schedule. With this upgrade, users can now receive this information directly from the Dashboard.

What's Different:

PowerSteering reports and Data Extracts can now be scheduled to run multiple times a day.

Prior to this release, the Details and Schedule tab only allowed users to run their reports once per day at most. Selecting Daily from the "Frequency" field allowed users to choose how many days they wanted the report to run, but they could not configure it to run more than once during the same day.

With this update, users can choose an hourly interval for running reports.

Note: Speak to your PowerSteering representative to customize these intervals.

Tip: Avoid running large reports more frequently than necessary. Running large reports too often can lead to slower application performance. Reach out to your PowerSteering representative for tips on the correct interval for your report.

Benefit:

In a fast-paced work environment, PowerSteering data can change rapidly and running reports once per day is often not enough. Users can now receive reports multiple times per day, making it easier to monitor changing information and make timely decisions based on the latest available data.

What's Different:

Administrators can now specify which users will receive reminders from the Timesheet Reminder agent. Users can be selected directly, by User Group, or by associated Tags.

Note: Users only need to satisfy one of the criteria to receive the reminder. In other words, a user must be selected directly OR have the associated Tag value on their profile. They do not require both.

While editing this agent, users will find three new parameters that can be used to select which users will receive reminders.

• Select users/groups to notify: Directly select the checkbox of any user or User Group to send them reminders. Leaving the field empty will send the reminders to all users (unless a Tag has been selected from the "Select a Tag" field below).

  Note: Selecting a User Group will send reminders to all member of the group.

• Select a Tag: Select a Tag that will be used to determine which users receive reminders. This field works in conjunction with the "Select a Tag value" field below. Leaving the field empty will send the reminders to all users (unless any users or User Groups have been selected from the "Select users/groups to notify" field above).

• Select a Tag value: Select which Tag value users must have associated with them in order to receive reminders.

Example: In Christie's organization, users only submit PowerSteering Timesheets if their hours are billable. She would like to take advantage of the Timesheet Reminder agent to remind users to complete their Timesheets, but she does not want to send unnecessary emails to users who do not need to submit them. To overcome this, she creates a new Tag called "Resource Billable?" and associates it with users. Whenever she adds a new user with billable time, she sets the "Resource Billable?" Tag to "Billable" on their profile.
She targets these users with the Timesheet Reminder agent by selecting the Tag and its corresponding value from the parameters:

Alternatively, she could have created a User Group called "Billable Users" and added each user who uses the Timesheet. Then, she could simply select the User Group from the "Select users/groups to notify" parameter to target them for reminders.

Benefit:

Not all PowerSteering users are expected to use Timesheets. Sending out Timesheet reminders to users who do not submit Timesheets can cause confusion and unnecessary email traffic. By targeting specific users, administrators can make sure that reminders are always send out to relevant users.