Roles and permissions — legacy configuration guide
Before configuration
Identify whether the target screen is legacy, nextgen or a hybrid journey. Record the intended recipients, allowed actions and visible employee population separately. Prepare one representative recipient and both an in-scope and out-of-scope record for validation. Use the functional guide to distinguish membership from visibility.
Evidence: local sources, connected Confluence pages and read-only smartmobility.io inspection on 15 October 2026. Observed in application applies to the English/French nextgen role editor, search and preset dialogs. Writes, grants and activation were not performed. Other implementation claims are Verified in code unless marked Documented in Confluence or Not verified.
Configuration ownership and generation
| Owner / scope | Legacy | Nextgen |
|---|---|---|
| Project / platform core | Tenant activation, legacy profile catalogue and navigation rights; privileged setup surface | Permission catalogue, preset definitions, hybrid integration, space access and privileged initialization |
| Customer administrator / functionality | Available legacy controls depend on delegated access; the prescribed functional test account was denied Configuration during this inspection | Settings > Roles: localized role information, actions, population and visibility attachments, subject to separate permissions |
The shell's appearance does not identify the embedded implementation. Observed in application: the Roles screen in the manager shell embeds nextgen content. Documented in Confluence: the SMR playbook, version 3, 24 September 2026, separates legacy menu rights and nextgen action permissions. Current code can also consult nextgen scopes when building the menu, so both layers need checking.
Project/platform core — legacy configuration
Create the permission profile
Open the available legacy profile administration. The implemented form contains a role name and a hide from access list checkbox. Name the profile for its responsibility, for example “Regional HR — employee reading”. The hide option controls presentation and must not be used as an access-removal procedure.
The legacy controller lists profiles for the current organization's setting. Its list, matrix and edit paths contain restrictions on subordinate manager accounts. Use the authorized administration journey; the role name alone does not grant entry to this screen.
Configure the rights matrix
- Open the matrix showing one column per profile and one row per catalogue right.
- Locate the profile and select the actions required for its responsibility.
- Clear actions that the profile should no longer grant.
- Wait for the automatic save and success notification, then reload to confirm persistence.
- Review the profile's users and validate access through the actual target module.
The save operation writes the complete selected right-code list for each submitted profile. A profile with all checkboxes cleared receives an empty list. Avoid simultaneous edits to the same matrix: the inspected action replaces lists and does not establish conflict resolution.
Review recipients and effective access
The profile member listing combines manager-profile attachments and user permission assignments, deduplicating users. The general voter also accepts tokenizer-derived rights, which are not established by that listing. Review all applicable sources when changing a user's access.
Do not infer a nextgen-style visibility-group configuration from the legacy matrix. Review the target module's relationship and population settings separately. For People Review, campaign relationships and campaign administrator status affect the population; see its configuration guide.
Customer administrator — legacy availability
Observed in application: the prescribed functional test account could open the nextgen Roles list, but its user-menu Configuration entry returned “You are not authorized to access this resource”. These are distinct authorization surfaces. No legacy matrix screenshot was captured and no legacy setting was changed.
Documented in Confluence: the April SMR - Roles & permission guidance, version 4, 10 April 2026, keeps the old system out of end-user exposure and places setup with the project team when the redesign module is unavailable. Later July/September guidance describes a hybrid transition. Do not promise every customer administrator access to the legacy matrix; request the authorized project team's intervention where it is not delegated.
Validate the resulting access
After applying a role change, reopen the role and review its Permissions, Visibility and Population totals and entries. Then use an account that receives the role to confirm the intended workflow:
| Review | Expected result |
|---|---|
| Intended action on an in-scope record | The recipient can complete the permitted action. |
| Excluded action | The recipient cannot perform that action. |
| Record outside the intended population | The module applies its documented visibility rules. |
| Direct assignment removed while a group remains | The role still appears through the group assignment. |
| Final intended grant removed | The recipient no longer has the action through another role or group. |
| Visibility narrowed | Each affected permission reflects the intended scope; user-level visibility is also reviewed. |
| Campaign workflow | Campaign assignment, relationships and workflow stages are checked separately. |
Use a recipient account with the intended role and scope. Privileged administrator access can produce a different result from ordinary recipient access.
Hybrid deployments
Legacy contains a hybrid-mode service that fetches nextgen right slugs and a service that requests nextgen administrator initialization. These establish integration paths, not full synchronization of profiles, roles, recipients and scopes. Configure and validate each target implementation; no automatic migration or permission-equivalence guarantee was verified.
See the technical guide for source references and the API contract used by the editor.
Additional references and interface differences
Documented in Confluence: SMR - Roles & permission, version 4, 10 April 2026; Back-office V3, version 2, 8 July 2026; Playbook SMR, version 3, 24 September 2026. The April page's exclusion intent is not proof that later hybrid code stopped using legacy authorization. The later guidance and inspected code describe coexistence. “One group = one role” in the playbook is a deployment recommendation, not a database cardinality restriction.
The Visibility System, version 9, 11 October 2023, documents historical visibility setup and broad-right precedence. Its historical participant prerequisites and rollout phases were not verified as current nextgen requirements and are not carried into these steps.
The supplied KBCT entry returned 404. The supplied PS pages were read: Delivery Philosophy & Project Methodology, version 7, 30 December 2025, and Onboarding/learning and partner certification, version 9, 18 February 2026. They provide methodology, not field defaults or permissions.
The technical guide describes legacy/nextgen coexistence and the implementation details behind role permissions. Available controls depend on your assigned administration permissions and the workspace generation.
Last updated on 3 November 2026