Role Mining Prompts

Layer 1 — baseline by Employee Type

Show me an access matrix for users with employee type = FTE with assignment % > 30%. Use birthright threshold of 80%.

An access matrix for FTEs across all apps, with birthright vs. self-service recommendations.

Establish the company-wide baseline every full-time employee should get on Day 1.

Layer 2 — by department or business unit

Show me an access matrix for users with [department attribute] = [Department Name] with assignment % > 30%. Use birthright threshold of 80%.

Optional add below:

Exclude apps already marked birthright above.

An access matrix scoped to the department, showing incremental apps beyond the Layer 1 baseline.

Capture team-specific apps (Engineering → GitHub, Sales → Salesforce) without duplicating the company baseline.

Layer 3 — by team (only if needed)

Show me an access matrix for users with [team attribute] = [Team Name] with assignment % > 30%. Use birthright threshold of 70%.

Optional add below:

Exclude apps already marked birthright above.

An access matrix for the team, showing only the long-tail apps unique to that team.

Add team-level granularity for specialized tooling (e.g., Security → Datadog admin) without over-fragmenting policies.

Split by a secondary attribute

Show me an access matrix for users with [attribute] = [Value] split by [secondary attribute].

A matrix where rows are apps and columns are the distinct values of the secondary attribute.

Compare access patterns across subsidiaries, regions, or sub-teams in one view.

Permissions matrix — by Employee Type

Show me a permissions matrix for [App Name] for users with employee type = FTE with assignment % > 20%. Use birthright threshold of 80%. Exclude groups containing '_dl', 'location', or 'all-employees'.

An entitlement-level matrix showing which groups, roles, or profiles should be birthright across the FTE population.

Define the right level of access inside an app, not just whether someone gets the license.

Permissions matrix — by department or team

Show me a permissions matrix for [App Name] for users with [department attribute] = [Department Name] with assignment % > 20%. Use birthright threshold of 70%. Exclude entitlements already marked birthright at Layer 1.

A department- or team-scoped entitlement matrix layered on top of the Layer 1 baseline.

Handle apps like Salesforce where Sales needs profiles other departments don't, or where one engineering sub-team needs admin roles.

Decide policy depth (5-user rule)

For my access policies: if only one team in a department has 5+ users and all others have <5, build at department level. If two or more teams have 5+ users, build at department + team level. Show both groups as tree diagrams with user counts.

Two grouped trees — departments to handle at department level vs. departments to break out by team.

Avoid over-fragmenting (one policy per tiny team) and under-fragmenting (one policy hiding real variance).

Compare attribute granularity

Do sub-teams under [Department Name] have meaningfully different access? Compare the access matrix at the department level vs. the team level for this department.

A side-by-side or summary showing whether breaking out by team surfaces meaningfully different access.

Know when to stop adding layers — if the deeper level looks the same, don't build it.

Teach a naming convention

Remember: any group name containing '_dl' is a distribution list and should be excluded from permissions matrices by default.

Confirmation Albus has stored the rule; future matrices apply it automatically.

Train Albus on your conventions once instead of repeating exclusions every prompt.

Teach a location pattern

Remember: groups starting with a country or city name (e.g., 'usa_', 'london_') are location-based distribution lists, not access controls.

Confirmation the rule is stored.

Filter out noise from location-based groups across every future matrix.

Teach an exclusion rule

Remember: apps labeled "deprecated" should never appear in birthright recommendations.

Confirmation the rule is stored.

Keep retired apps out of policy recommendations.

Exclude an app entirely

Remember: ignore [App Name] and exclude it from matrices.

Confirmation the app will be filtered from future matrices.

Pull noisy or out-of-scope apps (sandboxes, test environments, internal tools) out of every recommendation.

Identify gaps in existing policies

Identify potential gaps in existing access policies by analyzing application assignment coverage. Look for apps assigned to 60–90% of [employee group] — that range often indicates a missing policy.

A table of apps with partial coverage, with coverage % and a suggestion for whether to promote to birthright.

Surface near-birthright apps that should be promoted, and inconsistencies in current assignments.

Top-requested apps segmentation

For the top 5 most-requested apps in the last quarter, show me recommended access policy segmentation and the rationale for each.

A breakdown of the top 5 apps with proposed segmentation and reasoning grounded in request data.

Prioritize policy work where it eliminates the most tickets.

Find apps missing access groups

Looking at my Okta apps, which entitlements are missing a corresponding access group? Use the naming convention "APP-[app name]" to check.

A list of Okta apps without a backing access group.

Prep work for moving birthright orchestration off of IdP rules and into Lumos policies.