> ## Documentation Index > Fetch the complete documentation index at: https://help.doozy.live/llms.txt > Use this file to discover all available pages before exploring further. # Access Rules > Choose who gets Doozy access and when access is removed. Doozy syncs people from your connected Slack workspace into Members. A connected HR system adds employee details and can add eligible hires. Access rules decide who gets active Doozy access, including people already in your workspace. Choosing people manually does not stop Slack from syncing them into Members. Only workspace Admins can view or change access rules. The API calls this role `owner`. ## Choose who gets access Open **Settings** → **Members & access** → **Access rules**. | Choice | What happens | | - | - | | **Everyone in your Slack workspace** | People added to Doozy receive access without needing to match group or HR-system conditions | | **People who match conditions** | People receive access when they meet the conditions you select | | **Specific people** | Choose access individually or in bulk in the review dialog, then confirm | You choose whether removal or deactivation in Slack automatically removes Doozy access. HR termination and preboarding have separate rules, described below. ### Match people to rules You can require membership in selected groups, a record in your connected HR system, or both. * **Groups:** a person must belong to at least one selected group. * **HR system:** a person must have a linked employee record. This choice appears when an HR system is connected. It also allows eligible employees whose start date has arrived to be added from HR even without a matching Slack account. * **Both:** the person must have the HR record and belong to at least one selected group. If a saved rule depends on a disconnected HR system or an unavailable group, the page keeps that rule visible so you can repair it. Check the rule before applying other changes. ### Decide when to remove access In every access mode, choose **Remove their access to Doozy** or **Keep their access to Doozy**. This controls whether removal or deactivation in Slack removes Doozy access, including for Admins. The last Admin still in Slack always keeps access. Keeping access preserves existing roles; it does not re-enable people who are already disabled. People added only through HR who have never had a Slack account are not considered removed from Slack. For **People who match conditions**, the same choice also controls removal when someone stops matching your group or HR-record conditions. Admins retain access when they stop matching those conditions. HR termination remains separate. Uninstalling the Doozy integration preserves everyone's existing roles and access state. After reconnection, Doozy checks current Slack membership and follows your saved automatic-removal setting for people who left or were deactivated while the integration was uninstalled. ## Review and confirm changes 1. Choose your access and removal options. Selecting an option does not save it. 2. Select **Review changes**. 3. For automatic rules, inspect the affected people and how future access will work. For **Specific people**, select roles in the dialog, individually or in bulk. Changes to roles in this dialog are not saved yet. Any removals caused by your rules are shown here too. 4. Select **Confirm** to save. **Cancel** closes the dialog without applying your choices. **Review changes** is enabled only when your settings have changed. Under **Specific people**, select **Edit people** to open the member dialog at any time. **Confirm** is enabled once you change a role or have settings to save. The settings page does not contain a member table or save unfinished settings as a draft. Leaving the section drops unconfirmed settings. If some individual role updates fail, successful changes stay saved. Confirm again to retry the failed people. If access-rule application fails or stops progressing, use **Retry** to reapply the saved rules. Saving access rules preserves preboarding settings. The review reflects the workspace when it is calculated; a Slack or HR update before confirmation can change who is affected. The application status shows when background access updates are still running or have failed. Existing individually granted exceptions stay in place until an Admin confirms new access rules. Reviewing changes alone does not change access. Historical Slack disconnection records do not revoke existing access unless an individual removal is confirmed. ## Individual roles and HR lifecycle Assigning a role, individually or in bulk, does not exempt a person from access removal. Active Members and Managers still follow your access rules. If you explicitly set someone to **Disabled**, automatic rules do not enable them again. When automatic rules re-enable someone, they receive the **Member** role regardless of their previous role. An Admin must explicitly assign Manager or Admin access again. **Specific people** does not restore active-member access automatically. Uninstalling the Slack integration preserves everyone's existing roles. HR termination removes access from non-admins even if their role was assigned by hand or automatic removal is off. Admins retain access when they fail group or HR-record conditions, or are marked inactive in HR. Slack removal or deactivation removes their access only when automatic removal is enabled, and never from the last Admin still in Slack. Preboarders are managed by their [preboarding lifecycle](/preboarding/overview), rather than receiving active-member access through these rules. Termination or disconnection from HR removes their preboarder role. Slack removal or deactivation removes their access when automatic removal is enabled; if they return to Slack, an eligible preboarder returns to preboarding, never directly to Member access. These changes do not count as active-member access changes in the review. Removing access retains the person's historical data. Their participation in ongoing tracks stops; see [disabling a user](/admin/how-to-change-user-permissions#faq) for the effects on activities and mentor pairings. ## See also Choose which roles can schedule each activity Review and update access rules programmatically This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.