docs: update Directory nav relabels (Directory sources, Dynamic groups)

product/admin/attributes.mdx

@@ -23,7 +23,7 @@
 
 **Standard** user attributes are pre-defined by C1 (the list of these is shown below). This data is shown in the **User details** section of the user's page. 
 
 Standard attribute data is displayed on each user's details page and on the summary tooltip that's shown when you hover over a user's name. It's useful for giving reviewers, admins, and managers a complete picture of who a user is when making decisions about access. 
 
 **Custom** user attributes are defined by your organization. This data is shown in the **Profile attributes** section of the user's page. 
 
@@ -39,7 +39,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources** and select the **Attribute manager** tab.  
+Navigate to **Directory** > **Directory sources** and select the **Attribute manager** tab.  
 
 </Step>
 <Step>
@@ -54,7 +54,7 @@
    - Manager Email* 
    - Directory Status (the employee's status in the IdP, such as active, suspended, or deleted)
    - Employment Type (such as full-time employee, contractor, intern)
    - Employment Status (the employees's status in the HR system, such as active, suspended, or deleted)
    - Department
    - Job Title
    - Additional Username*
@@ -120,7 +120,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources** and select the **Attribute manager** tab.  
+Navigate to **Directory** > **Directory sources** and select the **Attribute manager** tab.  
 </Step>
 <Step>
 Click **Add attribute**. 

product/admin/directory.mdx

@@ -12,7 +12,7 @@
 
 This single source of truth is typically one of these:
 
 * Your Identity Provider (IdP), such as Okta, Azure AD, or Google Workspace.
 
 * Your Human Resources Information System (HRIS), such as BambooHR or Workday, especially if it serves as the ultimate source of truth for all employee records.
 
@@ -60,19 +60,19 @@
 
 #### One person, many apps
 
 A user has accounts in Okta, GitHub, Workday, and Slack. All four accounts link to one C1 user via primary-email match, and profile attributes are aggregated from each app according to the configured [attribute mapping priorities](/product/admin/attributes).
 
 #### Identity provider plus apps
 
 When an IdP connector (Okta, Entra ID) is configured, it typically syncs the largest set of identities and serves as the de-facto source of truth — most other apps' accounts find a C1 user to link to via the IdP's primary emails. The IdP also produces an IdP record per user, which keeps the C1 user retained for audit even after every other account is removed.
 
 #### Service account aliased to a human
 
 A human's secondary email is also listed as a service-account address in your directory app. Without intervention, the alias-email match path can link the service-account to the human's C1 user. Resolve this by unlinking the service account in the C1 UI, or by filtering service accounts out at the [directory level](/product/admin/directory#optional-limit-which-accounts-will-be-pulled-into-c1) using `IGNORE`. For service accounts in non-directory apps, only the UI unlink applies.
 
 #### MATCH_ONLY directory for shadow imports
 
 A secondary HR system is configured in `MATCH_ONLY` mode so its accounts can enrich C1 users with HR attributes (employee ID, manager, and so on) without inflating the user count. Accounts from that directory that don't match an existing C1 user are left unmerged until a primary-directory account creates the identity.
 
 ## Connect a directory and create user accounts
 
@@ -92,7 +92,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources**.
+Navigate to **Directory** > **Directory sources**.
 
 </Step>
 <Step>
@@ -153,7 +153,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources**.
+Navigate to **Directory** > **Directory sources**.
 </Step>
 <Step>
 Open directory settings by doing one of the following:

product/admin/groups.mdx

@@ -19,7 +19,7 @@
 
 * **Organizing employees without creating custom IdP groups.** C1 groups make it easy to create groups of employees who share key profile attributes or combinations of access. 
 
 * **Specifying who is granted an access profile.** An access profile can be requestable by, or automatically assigned to, a C1 group. 
 
 * **Assigning a group as reviewer on a policy step.** A C1 group can be set as a policy step reviewer. 
 
@@ -45,7 +45,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **Groups** and click **Create group**.
+Navigate to **Directory** > **Dynamic groups** and click **Create group**.
 </Step>
 <Step>
 Give your new group a name and add a description. Click **Create group**.
@@ -58,7 +58,7 @@
 
    - Use the **Basic** condition builder to construct a rule from a combination of entitlements and [profile attributes](/product/admin/attributes) (see note below on which profile attributes are supported), with the option to add **and** and **or** statements to refine the rule.
    <Tip>
    **Supported attributes in the basic condition builder** The value input field in the basic condition builder currently only supports string values. Certain attributes are stored as enums (fixed lists of values) or arrays (multiple values), which cannot be correctly parsed when entered as a simple string in the basic builder. If you use these attributes in the basic builder, the system will treat the input as a literal string, and the policy or membership rule may not behave as expected.
 
    The following attributes are not supported in the basic condition builder:
 
@@ -70,7 +70,7 @@
 
    If you need to use any of the attributes listed above, you must compose a CEL expression in the **Expression** field.
    </Tip>
    - Use the **Expression** field to to compose a [CEL expression](/product/admin/expressions) that describes the membership rule.
 </Step>
 <Step>
 Click **Preview** to check the syntax of your membership rule.<br/><br/>
@@ -95,7 +95,7 @@
 
 <Steps>
 <Step>
-On the **Groups** page, find the group you want to duplicate. 
+On the **Dynamic groups** page, find the group you want to duplicate. 
 </Step>
 <Step>
 Click the **...** (more actions) menu, then choose **Duplicate**.

product/admin/profile-types.mdx

@@ -11,7 +11,7 @@
 
 In C1, profile types provide the foundation for managing user data with precision and efficiency. They offer a powerful way to segment your workforce and ensure that your administrators and reviewers only see the information relevant to a specific user group.
 
 Profile types solve the challenge of managing diverse user populations (like full-time employees, contractors, and vendors) within a single system. Instead of applying every possible user attribute to every single person, profile types allow you to select a specific, tailored set of attributes (like work_location or contract_end_date) that are relevant only to that group. This eliminates noise and makes user profiles cleaner and easier to read.
 
 Profile types also enable powerful filtering and segmentation when creating User Access Review (UAR) campaigns and policies. You can build rules based on both the profile type and the specific attributes within it. 
 
@@ -35,7 +35,7 @@
 
 Here's the full lifecycle of a custom attribute:
 
 1. **Connector syncs data from the source system.** When a connector syncs with a source application (like Workday, Active Directory, or Okta), it pulls user account data into C1. This data is stored on the user's **account** within the connected application. Custom fields from the source system are included in the account's profile as key-value pairs.
 
 2. **You create an attribute mapping.** In the [Attribute manager](/product/admin/attributes), you create a custom attribute and tell C1 which application and which field to pull the data from. This is how C1 knows, for example, that "Employment Type" should come from the `employmentType` field on the user's Workday account.
 
@@ -58,7 +58,7 @@
 Make sure your Workday connector is set up and syncing. After a sync completes, the Cost Center value is stored on each user's Workday account.
 </Step>
 <Step>
-Navigate to **Directory** > **User data sources** > **Attribute manager** and click **Add attribute**. Select **Custom**, name it "Cost Center", and use **Direct mapping** to select your Workday application and the `costCenter` field. Click **Create**.
+Navigate to **Directory** > **Directory sources** > **Attribute manager** and click **Add attribute**. Select **Custom**, name it "Cost Center", and use **Direct mapping** to select your Workday application and the `costCenter` field. Click **Create**.
 </Step>
 <Step>
 Navigate to the **Profile types** tab and select (or [create](#create-a-new-profile-type)) the profile type you want to associate this attribute with, such as "Full-time employees". On the **Details** tab, click **Edit**, select the **Cost Center** attribute, and click **Save**.
@@ -80,7 +80,7 @@
 Make sure your Active Directory connector is set up and syncing. After sync, the `githubUserName` value is available on each user's AD account.
 </Step>
 <Step>
-Navigate to **Directory** > **User data sources** > **Attribute manager** and click **Add attribute**. Select **Custom**, name it "GitHub Username", and use **Direct mapping** to select your Active Directory application and the `githubUserName` field. Click **Create**.
+Navigate to **Directory** > **Directory sources** > **Attribute manager** and click **Add attribute**. Select **Custom**, name it "GitHub Username", and use **Direct mapping** to select your Active Directory application and the `githubUserName` field. Click **Create**.
 </Step>
 <Step>
 Add the **GitHub Username** attribute to the appropriate profile type and make sure the relevant users are assigned to it.
@@ -118,7 +118,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources** and select the **Profile types** tab.  
+Navigate to **Directory** > **Directory sources** and select the **Profile types** tab.  
 
 </Step>
 <Step>
@@ -178,7 +178,7 @@
 
    - Use the **Basic** condition builder to construct a rule from a combination of entitlements and [profile attributes](/product/admin/attributes) (see note below on which profile attributes are supported), with the option to add **and** and **or** statements to refine the rule.
    <Tip>
    **Supported attributes in the basic condition builder** The value input field in the basic condition builder currently only supports string values. Certain attributes are stored as enums (fixed lists of values) or arrays (multiple values), which cannot be correctly parsed when entered as a simple string in the basic builder. If you use these attributes in the basic builder, the system will treat the input as a literal string, and the policy or membership rule may not behave as expected.
 
    The following attributes are not supported in the basic condition builder:
 
@@ -190,7 +190,7 @@
 
    If you need to use any of the attributes listed above, you must compose a CEL expression in the **Expression** field.
    </Tip>
    - Use the **Expression** field to to compose a [CEL expression](/product/admin/expressions) that describes the membership rule. 
 
      Click **Preview** to check the syntax of your CEL expression. Note that not all users who match the membership rule will be shown immediately when you click **Preview**. 
 </Step>

product/admin/push-rules.mdx

@@ -24,7 +24,7 @@
 Attribute push rules are currently available for:
 
 - Active Directory
 - Microsoft Entra ID 
 
 Each connector reports its own supported schema and whether it supports custom attributes.
 
@@ -60,13 +60,13 @@
 
 - The **Super Admin** role in C1
 - A configured connector for the target application
-- User attribute mappings defined in C1 (**Directory** > **User data sources**)
+- User attribute mappings defined in C1 (**Directory** > **Directory sources**)
 
 ### Create a push rule
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources**.
+Navigate to **Directory** > **Directory sources**.
 </Step>
 <Step>
 Select the **Push rule** tab.
@@ -102,7 +102,7 @@
 
 <Steps>
 <Step>
-Navigate to **Directory** > **User data sources** > **Push rule**.
+Navigate to **Directory** > **Directory sources** > **Push rule**.
 </Step>
 <Step>
 Find the push rule in the list.