# Provisioning The OnGuard connector supports provisioning, allowing you to create and manage accounts and entitlements in OnGuard directly from SailPoint. **Prerequisite:** Your system is configured for provisioning. When SailPoint provisions new accounts to the source, it uses the attributes on the **Create Account** page as instructions or a template for what to include in the account. This page is also referred to as the *provisioning policy*. When new access is granted on a source where a user does not already have an account, SailPoint automatically includes account creation in the provisioning. This applies whether provisioning is started from an access request or from an automated role or lifecycle state assignment. For direct-connect sources, SailPoint automatically creates the account from this configuration. If the source is not configured as a direct-connect source, SailPoint creates and assigns a provisioning task to the source owner and includes the values for the source owner to use in manually creating the account. > [!IMPORTANT] > > This section describes the default **Create Account** configuration. SailPoint recommends that you work with Services to define a provisioning configuration specific to your company's needs. Be sure to verify large changes to the provisioning policy before implementation. Failure to do so might cause provisioning to fail. ### Creating Accounts When Segmentation Is Enabled If segmentation is enabled, account creation works as follows: 1. If **Access to All Segments** is selected in **Segment Settings**: - You can specify both **Primary Segment** and **Additional Segments** when creating a cardholder. - If **Primary Segment** is not provided, the cardholder will be created in the default segment, ``. 2. If **Access to a Specific Segment (Segment Unit)** is selected in **Segment Settings**: - The cardholder will always be created in the configured segment. - Creating cardholders in any other segment is not supported. - Assigning **Additional Segments** is not allowed in this configuration. 3. If **Access to a Specific Segment (Segment Group)** is selected in **Segment Settings**: - The Primary and Additional Segments provided during cardholder creation must meet one of the following conditions: - They match the configured segment group. - They are member segments within that group. For example, if the configured group is United States, allowed values include: 1. United States (group) 2. Austin, New York (member segments of United States) - Creating a cardholder in a segment outside the configured group is not supported. ## Default Create Account Attributes | Attribute Name | Description | | --- | --- | | First Name | The cardholder's first name | | Last Name\* | The cardholder's last name | | Email Address | The cardholder's email address | | City | The cardholder's city | | State | The cardholder's state | ## Configurable Attributes | Attribute Name | Description | | --- | --- | | Middle Name | The cardholder's middle name | | Location | The name of the cardholder's location | | Title | The cardholder's title | | Office Phone | The cardholder's office phone number | | Allowed Visitors | Indicates if the cardholder is allowed to have visitors | | Building | The cardholder's building | | Department | The cardholder's department | | Division | The cardholder's division | | Extension | The cardholder's phone extension | | Floor | The floor that the cardholder is assigned to | | Primary Segment | Primary Segment of a cardholder. This attribute will be visible only when segmentation is enabled . | | Additional Segments | Additional Segments of a cardholder. This attribute will be visible only when segmentation is enabled. | > [!NOTE] > > Parameters marked with an asterisk (\*) are mandatory. ### Adding Custom Attributes for Account Creation You can add customer-specific custom attributes to the Create Account provisioning policy. Add each attribute using its OnGuard internal field name, for example, `CUSTOM_ATTR`. Add each custom attribute to both the account schema and the provisioning policy, using the same internal field name. If you add the attribute only to the provisioning policy, the connector does not send it. ## Update Account Attributes | Attribute Name | Description | Out of the box / Configurable | | --- | --- | --- | | First Name | The cardholder's first name | Configurable | | Last Name | The cardholder's last name | Configurable | | Middle Name | The cardholder's middle name | Configurable | | Email Address | The cardholder's email address | Configurable | | City | The cardholder's city | Configurable | | State | The cardholder's state | Configurable | | Location | The name of the cardholder's location | Configurable | | Title | The cardholder's title | Configurable | | Office Phone | The cardholder's office phone number | Configurable | | Allowed Visitors | Indicates if the cardholder is allowed to have visitors | Configurable | | Building | The cardholder's building | Configurable | | Department | The cardholder's department | Configurable | | Division | The cardholder's division | Configurable | | Extension | The cardholder's phone extension | Configurable | | Floor | The floor that the cardholder is assigned to | Configurable | | Primary Segment | Primary Segment of a cardholder. This attribute will be visible only when segmentation is enabled . | Configurable | | Additional Segments | Additional Segments of a cardholder. This attribute will be visible only when segmentation is enabled. | Configurable | ### Adding Custom Attributes for Account Updates You can add customer-specific custom attributes to the Update Account provisioning policy. Add each attribute using its OnGuard internal field name, for example, `CUSTOM_ATTR`. Add each custom attribute to both the account schema and the provisioning policy, using the same internal field name. If you add the attribute only to the provisioning policy, the connector does not send it. ### Updating Accounts When Segmentation Is Enabled 1. If **Access to All Segments** is selected in **Segment Settings**: - You can update both **Primary Segment** and **Additional Segments** for the cardholder. 2. If **Access to a Specific Segment (Segment Unit)** is selected in **Segment Settings**: - Updating **Primary Segment** or **Additional Segments** is not supported. - The cardholder remains associated with the configured segment only. 3. If **Access to a Specific Segment (Segment Group)** is selected in **Segment Settings**: - You may update the Primary and Additional Segments only if: - They match the configured segment group. - They are member segments within that group. For example, if the configured group is United States, allowed values include: 1. United States, Austin, or New York. - Updating to segments outside the configured group is not supported. ## Enabling and Disabling Accounts ### Enabling Accounts This operation enables the cardholder's most recently modified badge. > [!NOTE] > > The default deactivation date of the badge will be set to 5 years from activation. ### Disabling Accounts This operation deactivates all active badges assigned to a cardholder. The deactivation date is set to the current date, and the status is applied based on the Default Deactivation Status configured during setup. For more information, refer to [Deactivation Settings](). ## Adding and Removing Entitlements ### Adding Entitlements to Cardholders The connector supports assigning the following entitlements to the cardholder: - **Badge Type** This operation creates a new, unique badge of the respective badge type for the cardholder. - **Access Level** The access level operation works in two ways: 1. Assign Access Level - If the access level has not been previously assigned, this operation assigns it across all active badges. - The activation date is set to the current date, and the deactivation date is left null. 2. Activate Access Level - If the access level has already been assigned but is currently deactivated, this operation reactivates it for the badge. - The activation date is set to the current date, and the deactivation date is left null. > [!NOTE] > > When both the Badge Type and Access Levels are selected together, the specified access levels will be assigned to the newly created badge accordingly. ### Removing Entitlements from Cardholders The connector supports removing the following entitlements from the cardholder: - **Badge Type** This operation will remove all the badges of the respective badge type of the cardholder. - **Access Level** The access level operation has two options: 1. Remove Access Level - This operation permanently removes the specified access level assigned to the cardholder's badges. 2. Deactivate Access Level - This operation deactivates the access level assignment to the cardholder's badges instead of removing it. If not selected, the assignment will be permanently removed. The deactivation date is set to the current date. Refer to [Provisioning Settings]() for more information about deactivating access levels. If a badge type and an access level are selected together, the connector will prioritize the Badge Type, as it is considered a super-entity. As a result, all badges of the selected type will be permanently removed. Consequently, the associated access levels will also be removed automatically, since the badge itself no longer exists. > [!NOTE] > > If the use case requires deactivating or removing access-level assignments from badges, SailPoint recommends making a separate request by selecting only the access levels without selecting a badge type. This ensures that access levels are deactivated or removed from all active badges of the cardholder without deleting the badges themselves.