Role Mining Prompts

Generate the recommendation

Using /user-attribute-selection which attribute combinations are best for defining access policies?

A short plan to approve, then a measured analysis of every grouping attribute in your tenant.

Grounds policy design in your own data rather than an assumption about which attributes matter.

Approve the plan

(Click Approve CTA)

This plan looks good, go ahead.

Albus runs the full analysis and returns the recommended attribute set, a scorecard, and a coverage estimate.

The skill pauses before a long run so you can adjust the scope first.

Add context on the scale you expect

We are an enterprise organization and I expect a sizable number of access policies. Show me what a finer, team-level attribute adds beyond the top anchor.

A re-measure on absolute and residual contribution, showing what a finer attribute adds beyond the top anchor.

Albus tailors the analysis to the context you give it. Telling it the scale you are planning for gets you a deeper cut on the team-level layers.

Review the recommendation

Give me a clear overview of the attribute combinations you recommend for building access policies. Use helpful diagrams eg. mermaid diagrams and explain why an attribute was valid or not.

The recommended combinations, a diagram of how the layers stack, and the case for and against each attribute.

The reasoning is what you take into a working session, not just the answer.

Save the analysis

Save the report to my Knowledge Hub.

The analysis is written to your Knowledge Hub so later threads can read it.

Future conversations reference the same report instead of rerunning the analysis.

Check coverage before building

What % of access can I cover with layers 1 and 2?

The share of existing access captured as birthright, pre-approved, and self-service.

Tells you how much a policy set covers before you build a single policy.

Step 1 — the universal base

let's do a matrix for the everyone attribute

A single-column matrix across all active staff, showing the apps nearly everyone already holds.

Establishes the base so every layer after it only shows what it adds.

Step 2 — the top org layer

yes let's drill into [top-level org attribute]

The matrix for that layer across your business units.

Albus offers this at the end of the attribute overview, so you can answer in a few words.

Step 3 — the team layer

let's drill into [team attribute], filter out apps from the layer before

The team-level matrix, showing only access the layer above did not already grant.

Without the filter each layer repeats the apps above it and you cannot see what the layer contributes.

Step 4 — the carve-outs

now let's do [carve-out attribute], filter out apps from the layers before

The carve-out matrix, for example contingent workers or a region.

Completes the layered model. Albus keeps offering the next layer, so you can also just reply next.

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.

Permissions matrix — filtered by entitlement name

Show me a permissions matrix for [App Name] filtered to groups with [prefix] in the name.

An entitlement-level matrix limited to the groups matching that naming pattern.

Cuts a large app down to the entitlement family you care about instead of every group it has.

Find the groups that actually hold the access

Find user groups with the highest [App Name] assignment percentages.

Assigned over total per cohort, at both department and cost-centre grain, ignoring groups under ten members.

Scope the matrix to teams that genuinely hold the access rather than reading a wall of self-service.

Lower the bar on sparse access

Lower birthright % to 20.

The matrix re-rendered, showing which entitlements qualify at a lower threshold.

Role-specific apps rarely clear 80% in any team. Qualifying only at 20% signals pre-approval, not birthright.

Test whether a finer attribute helps

Does adding [attribute] as a combo attribute help increase percentages?

A comparison showing whether the combination concentrates the cohorts or fragments them.

A finer attribute only lifts percentages when it lines up with who holds the access. Usually it does not.

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.