Local groups can now be created directly in Tosca Cloud, giving release owners a platform-managed way to assign roles and workspace access when identity-provider synchronization is not the right operating path.
The September 2026 release also replaces manual entry of playlist characteristics with selectable values in a new Configurations tab. For enterprise test organizations, these are focused workflow changes: one improves access administration, while the other reduces configuration ambiguity before execution.
Create groups directly in Tosca Cloud
Administrators can now create groups in Tosca Cloud rather than relying only on groups synchronized from an identity provider. Local groups support the same core assignment model as synchronized groups:
- Assign Tosca Cloud roles to a group.
- Grant workspace access to a group.
- Manage group-based access without individual user-by-user assignment.
This matters when delivery teams need access structures that do not map cleanly to enterprise directory groups. Examples include time-bound program teams, external delivery partners, pilot workspaces, and specialized quality engineering functions.
The capability does not remove the need for centralized identity governance. It adds a second control path, so operating discipline matters more. Each locally created group should have a named owner, a documented business purpose, defined membership rules, and a periodic access review.
What access governance teams should decide
Local groups can shorten access provisioning lead time, but unmanaged local administration can create audit gaps. Security and platform leaders should set clear policy before broad adoption.
Recommended controls include:
- Define which use cases require local rather than SSO-synchronized groups.
- Restrict group creation to designated Tosca Cloud administrators.
- Apply least-privilege roles and workspace access by default.
- Record group owner, approval evidence, and expected retirement date.
- Review local-group membership on a scheduled cadence.
- Remove or disable groups after project closure or supplier offboarding.
For regulated delivery environments, local group creation should be incorporated into the access-control narrative used for internal audit and release assurance. The main question is not whether local groups exist; it is whether their creation, change, and retirement are traceable.
Select playlist characteristics from a configuration list
Playlist characteristics no longer need to be remembered and typed into a playlist. The new Configurations tab displays all available characteristics, allowing users to select the relevant values directly.
This is a small user-interface change with practical consequences. Manual text entry creates inconsistency: similar labels can be entered differently, values can be omitted, and release reporting may be harder to interpret. Selection from the available list improves the chance that teams use the intended configuration vocabulary.
For release owners, this supports more repeatable playlist preparation across squads. It is especially useful where playlists are organized around common execution attributes such as release scope, environment designation, application area, or internal test classification, subject to how the organization defines its characteristics.
Workflow impact for QA and DevOps teams
The September changes affect administration and test-execution preparation rather than test authoring or runtime behavior.
For QA leads: establish a controlled characteristic taxonomy and avoid near-duplicate values. A configuration list is only as useful as the underlying naming standard.
For DevOps teams: include local group governance in platform onboarding and offboarding procedures. Where CI/CD service identities or execution users need access, confirm the appropriate group and workspace permissions before pipeline rollout.
For release managers: use consistent playlist characteristics to improve operational handoffs. Teams should agree which characteristics are required before a playlist can be treated as release-ready.
For audit and risk teams: distinguish SSO-synchronized access from locally managed access in evidence collection. Both can be valid, but their source of authority and review process may differ.
Rollout and adoption considerations
Tricentis states that new capabilities are released gradually, so availability can take several days to reach an environment. Do not update standard operating procedures based solely on published notes; first confirm feature availability in the relevant tenant.
A practical adoption sequence is:
- Validate local-group creation and role assignment in a controlled workspace.
- Define approval and review requirements for locally managed groups.
- Identify any active project groups that should move from individual assignments.
- Review existing playlist characteristics for duplicates and unclear labels.
- Brief test leads and release coordinators on the Configurations tab.
- Capture evidence of the revised access and playlist-setup process.
This approach keeps a useful administrative option from becoming another unmanaged permission surface.
How Merito helps
Merito helps enterprise teams turn Tosca Cloud release features into governed operating practices. We assess access models across SSO, local groups, workspaces, and delivery roles; define permission and review standards; and help QA and DevOps teams establish playlist configuration conventions that support reliable release reporting.
For organizations scaling cloud test automation, Merito can also support rollout planning, administrator enablement, control evidence design, and integration of Tosca Cloud practices into broader SDLC governance.
Merito is an authorized Tricentis reseller and services partner, listed as a Certified Solution Partner in the Tricentis partner directory. Our Tricentis Tosca Cloud team can scope licensing, sizing, and rollout for September 2026, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.