> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumos.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Troubleshooting Access Policies
## After this article
You'll know how to diagnose and resolve issues where expected access requests weren't automatically kicked off as part of an employee's onboarding or mover workflow.
## Background
Within the Lumos platform, you can use Access Policies to dictate which employees should get access to which systems. Access Policies are structured into two elements:
* A **condition** that identifies a set of users (e.g. department = "Engineering")
* A **set of access** that should be granted to users that meet the condition
When a new employee joins your organization, Lumos runs an onboarding workflow, which evaluates these access policies and automatically grants birthright access to the user based on your policies.
Sometimes these requests don't get triggered as expected, leaving new hires without the access they need to be productive on day one.
This guide shows you troubleshooting steps to identify why access requests weren't generated and how to resolve the issue for both the current employee and future hires.
***
## Step 1: Confirm the Access Policy is Active
Access Policies can be set to Active or Inactive which determines if they will be assessed during Onboarding.
* Active: Policy will apply to any future onboardings
* Inactive: Policy will not apply to any future onboardings
## Step 2: Identify Affected Apps
Before diving into troubleshooting, you'll need to know which applications or permissions the employee should have received but didn't.
Common examples include:
* Core productivity tools (Microsoft 365, Google Workspace, Slack)
* Department-specific applications (Salesforce for Sales, GitHub for Engineering)
* Role-based permissions within applications
Make a list of the applications where access requests should have been generated but weren't. You'll use this list to investigate each policy individually.
## Step 3: Review Access Policy Conditions
Next, you'll want to identify the access policies that should have granted the user access. To do this, visit the [Employee Lifecycle > Onboarding](https://app.lumosidentity.com/user_onboardings?tab=IN_PROGRESS) page and select "Manage Access Policies". You should see a page like the one below:
For each application where access wasn't granted, examine the conditions that determine when access should be provisioned.
1. Navigate to the [Employee Lifecycle > Onboarding](https://app.lumosidentity.com/user_onboardings?tab=IN_PROGRESS) page and select "Manage Access Policies"
2. Use the search bar to find policies by application name (e.g., search "Slack" to find all Slack-related policies)
3. Click on each relevant policy to review its conditions
For each policy, review the conditions that must be true for access to be granted. Common condition types include:
* **Department** - Employee must belong to specific departments (e.g., "Engineering", "Sales")
* **Job Title** - Employee must have certain job titles or title patterns
* **Location** - Employee must be based in specific offices or regions
* **Employment Type** - Employee must be full-time, contractor, etc.
* **Manager** - Employee must report to specific managers or management chains
* **Start Date** - Employee must have started after a certain date
Take note of all conditions for each policy. You'll need to verify that the employee meets every single condition for access to be granted.
## Step 4: Examine the Employee's Attributes
Next, verify whether the employee's Identity in Lumos contains the correct attributes to match your access policies.
1. Navigate to the [Apps](https://app.lumosidentity.com/apps?view=bHVtb3MtZGVmYXVsdC1hbGwtYXBwcw%3D%3D) table in your Lumos admin panel
2. Select the application that represents your primary User Source in Lumos (usually your HRIS but in some cases may be your IDP)
3. Search for the employee by name or email
You should see the employee's account, along with columns representing all of the attributes on their Identity.
Compare the employee's attributes against each access policy condition you identified in Step 2. Look for examples of:
* **Missing Attributes**: Are any required fields completely blank?
* **Incorrect Values**: Do the attribute values exactly match what the policy expects? Look for issues such as:
* Spelling variations ("Engineering" vs "Eng" vs "Engineering Dept")
* Case sensitivity ("sales" vs "Sales")
* Extra spaces or special characters
## Step 5: Investigate Timing Issues
If the employee has all the correct attributes, the issue might be related to timing. Onboarding workflows run at a specific point in time, and if the employee attributes were populated after that time, it can lead to missing or incorrect access requests.
**Check when onboarding ran**
1. Navigate to [Onboarding](https://app.lumosidentity.com/user_onboardings?tab=COMPLETED) in your admin panel
2. Click on the Completed tab
3. Search for the employee by name or email
4. Note the date and time when their onboarding workflow completed
**Check when attributes were populated**
1. Navigate to [Mover Events](https://app.lumosidentity.com/user_movers?tab=events) in your admin panel
2. Filter the events to show only events tied to the employee whose access was not provisioned
3. Filter the events to show only events tied to the attributes used in the affected access policy
4. Look for events that show when each attribute was populated or updated
5. Pay attention to the timestamp of each event
**Verify Expected Timing**: Check if any attributes necessary for the policy were populated after the time that the onboarding workflow ran.
For example:
* Onboarding completed at 9:30 AM
* Department was updated to "Engineering" at 10:45 AM
* Access policy requires Department = "Engineering"
* Result: Access request wasn't generated because the condition wasn't met at 9:30 AM
## Step 6: Resolve the Issue
Once you've identified the root cause, you can take action to fix it for both the current employee and prevent future occurrences.
### For the Current Employee
**Grant Immediate Access**: Since the automated workflow didn't trigger, you'll need to manually provision access. You can do this either by re-triggering an onboarding, or by directly requesting access for the user in the AppStore. For the latter:
1. Navigate to your [AppStore](https://app.lumosidentity.com/app_store)
2. Find the application the employee needs, and select the tile in the AppStore
3. Click the "Access For" dropdown, and select the employee who needs access
4. Click Request Access and submit the request on behalf of the employee
### For Future Employees
In order to ensure that the root cause does not occur again for future employees, you can follow some of the below mitigation plans:
1. **If key Identity attributes were missing or incorrect**:
1. Work with your HR team to ensure:
1. Critical attributes are populated before or immediately after employee start dates
2. Attribute values follow consistent naming conventions
3. Required fields are marked as mandatory in your HRIS system
2. Update your Access Policy conditions to capture more users
1. Include both lowercase and uppercase versions of titles
2. Rely on more standardized fields such as job code, instead of directly relying on titles
3. Include more conditions in your policies
2. **If attributes were updated in the HRIS after the onboarding kicked off:**
1. Add a "Wait" step at the beginning of your workflow to ensure that onboarding runs after all HRIS changes are made
2. Configure [Mover Workflows](/kb/life_cycle_management/movers/mover-workflows) to capture changes made after an employee's first day
***
## Still Need Help?
If you've followed these troubleshooting steps and the issues with access policies still aren't clear, reach out to Lumos Support at [support@lumos.com](mailto:support@lumos.com) or in a shared Slack channel.