Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

03.06 Team-Based Segregation

Core SimpleRisk's team-based segregation — the always-on team filter that scopes which records a user can see based on team membership and per-record team assignment, with admin bypass and unassigned-record fall-through behavior.

Why this matters

Teams are SimpleRisk's basic unit of record-level access. A user assigned to the "Engineering" team sees risks, mitigations, and tests assigned to "Engineering"; they don't see records assigned only to "Finance." The team filter runs on every list query the application produces; it's how a 50-team install keeps each team's view of the register down to a tractable subset.

The honest scope to know up front: the Core team filter is always on, has no master toggle, and is not the same thing as the Separation Extra. Core's team filter answers which records can a user see based on team membership. The Separation Extra (see Separation of Duties) adds a finer role-based filter on top — within the records the team filter would let the user see, the Extra further controls visibility based on the user's role relative to that record. If you've never activated the Separation Extra, the team filter described here is your entire access-control surface for record-level visibility.

The other thing worth knowing: Core team segregation has a permissive default for unassigned records. A risk with no team assignment is visible to every user, regardless of their team membership. This is intentional (the system shouldn't trap orphaned records where nobody can see them) but it surprises operators who assume the team filter is strict. If a user reports "I see risks I shouldn't be able to see," check the team assignment first — an unassigned risk falls through to everyone.

The third thing: admins bypass the team filter entirely. A user with user.admin = 1 sees every record, every team, every assignment. The admin's view doesn't reflect what a non-admin user sees, so a "let me check what you can see" support session from an admin account is misleading; use a non-admin test account to validate team-segregation configurations.

Before you start

Have these in hand:

  • Admin access to manage teams (Configure → Teams) and to assign users to teams (Configure → User Management).
  • A planned team structure that maps to your operational reality. Common patterns: per-business-unit teams ("Finance," "Engineering"), per-function teams ("Application Security," "Vendor Risk Management"), per-region teams ("EMEA," "APAC"). Mix as fits your program; teams aren't hierarchical, so flat-list is the natural shape.
  • An understanding of the unassigned-record default. The Core filter falls through for records with no team assignment. If you need strict team-only visibility (no fall-through), the Separation Extra's allow_all_to_risk_noassign_team = '0' setting is the lever — but that's an Extra-gated feature.

Step-by-step

1. Define your teams

Sidebar: Configure → Teams opens the team management page (simplerisk/admin/team_management.php). The page lists existing teams and lets you add, rename, or delete teams.

To add a team:

  1. Enter the team name in the Add a New Team input.
  2. Click Add.
  3. The team appears in the catalog with a generated value (the internal id, written to the team table).

Naming guidance: use names that match the operational language of the organization. "Engineering" beats "ENG-01"; the names show up in dropdowns, dashboard filters, and reports throughout the application. If teams nest conceptually (Finance has Treasury and Accounting), capture the hierarchy in the name ("Finance.Treasury") since the team model itself is flat. For real organizational hierarchy, the Organizational Hierarchy Extra is the right tool.

Renaming or deleting a team affects every record currently assigned to it; renaming is safe (the assignment relationships in risk_to_team, mitigation_to_team, etc. point at the team's value, which doesn't change), but deleting strands assignments. Reassign records to a different team before deleting, or accept that the deletion implicitly removes the team-based-visibility constraint from those records.

2. Assign users to teams

Sidebar: Configure → User Management → [user] opens the user record. The Teams field is a multi-select; pick all teams the user belongs to. Saving the user record updates user_to_team.

Patterns:

  • Most users belong to one team — their primary working team.
  • Cross-functional users (auditors, leaders) belong to multiple teams; the union of their teams' records is what they see.
  • New admins automatically get all teams. When a user is promoted to admin (user.admin = 1), the application's set_all_teams_to_administrators() function writes a row in user_to_team for every team-id and the new admin user. This is a defensive measure: if the admin flag is later revoked, the user retains their assigned team memberships and isn't suddenly cut off from everything.

3. Assign teams to records

The team-assignment surface lives on the record itself. The patterns:

  • Risks — the risk submission form (sidebar: Risk Management → Submit Your Risks) and the risk details edit view (sidebar: Risk Management → Plan Your Mitigations) both have a Team multi-select. Assignment is multi-team; a risk can be visible to "Engineering" and "Application Security" simultaneously. Saving writes to risk_to_team.
  • Mitigations — the mitigation form on each risk has a Team multi-select. Saving writes to mitigation_to_team. A mitigation can be assigned to teams independently of the parent risk's teams.
  • Compliance tests — the test definition has a Team multi-select. Saving writes to items_to_teams with type='test'.
  • Compliance audits — the audit record has a Team multi-select. Saving writes to items_to_teams with type='audit'.

A few entities are not team-segregated in Core (notably assets — there is no asset_to_team table). Asset-related visibility comes from the Asset Management Extra and from the team-segregation Extras layered on top, not from a Core asset/team join. If you need strict per-team asset visibility, that's an Extra-driven configuration; Core asset visibility is broader.

4. Verify the filter with a non-admin account

Admins bypass the team filter; the admin's view is not representative. To validate the configuration:

  1. Pick or create a non-admin test user with a single team membership (say, "Engineering").
  2. Log in as that user.
  3. Open Risk Management → Plan Your Mitigations and confirm the visible risks are the union of: - Risks assigned to "Engineering" (the user's team), AND - Risks with no team assignment (the fall-through default).
  4. Confirm the user does not see risks assigned only to teams the user isn't a member of.

If the visible set is wider or narrower than expected, the cause is usually one of: an unexpected team assignment on the user record (check Configure → User Management → [user] → Teams), an unassigned record falling through (assign it to a specific team), or the Separation Extra is active and adding a layer of role-based visibility on top.

5. (Optional) Tighten the unassigned-record fall-through

By default, records with no team assignment are visible to every user — the Core filter's fall-through. For programs that need strict team-only visibility, the path is:

  • Operational discipline: enforce that every new risk, mitigation, test, and audit gets at least one team assignment at submission time. This is the lowest-friction approach but depends on user behavior.
  • The Separation Extra (see Separation of Duties) adds the allow_all_to_risk_noassign_team setting; setting it to '0' makes unassigned risks invisible to non-team users. Per-feature equivalents exist for documents (allow_all_to_document_noassign_team) and assets (allow_all_to_asset_noassign_team).

There's no Core-only setting for the fall-through; the operational-discipline approach or the Extra are the two options.

6. Plan for team changes

A common operational mistake: a team is renamed or restructured, but record-level team assignments aren't updated. Records keep pointing at the old team (which still works, since assignments are by value, not by display name) — but if the team is deleted, the assignment becomes orphaned and the records fall through to everyone-visible.

Reasonable cadence:

  • Quarterly: review the team catalog. Are all teams still in active use? Are there teams that should be merged or split?
  • At org-restructure events: walk the team-to-record assignments and re-assign as needed before deleting the old teams.
  • At user-onboarding: confirm the new user's team assignments match their actual responsibilities. Default to fewer teams; broader access can be granted later.

Common pitfalls

A handful of patterns recur with team-based segregation.

  • Validating from an admin account. Admin bypasses every team filter. The admin's view is wrong by construction; use a non-admin test account.

  • Forgetting the unassigned-record fall-through. "Why can the user see this risk? They're not on its team!" Check the risk's team assignment — if the assignment is empty, the risk is visible to everyone in Core, regardless of team membership. Either assign the risk to a team or activate the Separation Extra and configure allow_all_to_risk_noassign_team.

  • Deleting teams without reassigning records. Records assigned only to a deleted team become orphaned (the risk_to_team row points at a team.value that no longer exists in the team catalog). The Core filter treats these as unassigned and falls through to everyone-visible. Reassign records to a different team before deleting.

  • Confusing teams with permissions. A user with submit_risks permission can submit risks regardless of team membership; a user with no team membership but an explicit team assignment on a risk still sees that risk. Teams filter visibility, not actions. The two layers reason independently.

  • Trying to express hierarchy in flat teams. Core teams don't nest. "Finance.Treasury" and "Finance.Accounting" express hierarchy in the names but the system treats them as two unrelated teams. For real organizational hierarchy, the Organizational Hierarchy Extra adds business units above the team layer.

  • Assuming the team filter is strict by default. Core's filter is permissive: team-membership union plus unassigned-record fall-through plus admin bypass. If "strict team-only visibility" is your requirement, the Separation Extra adds the levers; Core alone won't get you there.

  • Not updating team assignments after user role changes. When a user moves to a different team, their user_to_team doesn't auto-update. The user keeps seeing the old team's records and may not see the new team's records. Include team-membership review in user-management workflows for role changes.

  • Granting admin to "fix" team-visibility issues. If a user can't see a record they should, the right answer is usually a team assignment (assign the user to the relevant team, or assign the record to the user's team). Granting admin bypasses all the access-control machinery, not just the team filter, and is rarely the right answer.

Related