Initial Platform Setup
This section covers everything an administrator needs to do in the Conga Advantage Platform before users can send or manage Sign transactions
Here, we cover creating and configuring users, understanding roles and permissions, and configuring Conga Sign Settings to shape the experience for your organization. If you are also connecting Salesforce to Sign, complete this section first, then proceed to Salesforce Connector Setup.
Understanding Platform User Model
Before creating any users, it helps to understand how the Platform structures access - because the terminology can be confusing if you're coming from a Salesforce background.
Platform users vs. Sign users
A Platform user is an account on the Conga Advantage Platform. A Sign user is a Platform user who has been granted access to the Conga Sign application specifically. All Sign users are Platform users, but not every Platform user needs Sign access. Think of it like adding someone to Salesforce (Platform user) vs. assigning them a product license (Sign user).
How authentication works
Users log in to the Platform using an Identity Provider (IDP). For most Conga Sign customers, this will be either:
Salesforce IDP - the user authenticates with their Salesforce credentials. The Platform maps them to their Platform account using their Salesforce User ID (External ID).
Conga IDP - the user authenticates directly with Conga using a username and password. The Platform sends them a welcome email with login credentials on account creation.
The IDP you use determines what goes in the External ID field and how the user logs in. Both paths lead to the same place - a fully configured Sign user - they just get there differently.
If your organization uses an enterprise identity provider such as Microsoft Entra (Azure AD), Okta, or Salesforce in a SAML 2.0 configuration, see Section 2.7 for SAML SSO setup steps. The Federation ID field on the user record (example in the Section 2.3 below) is used to map users when a SAML IdP is active.
User Types
When creating a user, the User Type field determines the nature of their account. For Conga Sign, you will primarily work with two types:
| User Type | When to Use |
|---|---|
| Internal | Standard users who are employees or members of your organization. This is the correct type for anyone who will be sending or managing Sign transactions. |
| Integration | System accounts created specifically for API connections or automated data sync between systems. Use this type for the dedicated Salesforce connector user. |
| Digital Commerce | External users interacting via a community portal. Not applicable to Sign use cases. Only available if the Enable Guest & Digital Commerce User option is enabled at the organization level. |
| Guest | External users needing temporary or restricted access. Not applicable to Sign use cases. |
Integration user credential warning: When an Integration user is saved, the Platform generates a Client ID and Client Secret for that account. Copy both values immediately - the Client Secret cannot be recovered after you navigate away from the page. There is no way to retrieve it; you would need to regenerate credentials entirely.
For the vast majority of Sign setups, you will be creating Internal users. The Integration user type is reserved for the dedicated connector user described in Salesforce Connector Setup.
Creating a User
Navigate to Admin Console → Users and click Add to open the User Details form.
Required Fields
| Field | Description |
|---|---|
| User Type | Select Internal for standard Sign users, or Integration for the connector user. |
| First Name | The user's first name. |
| Last Name | The user's last name. |
| The user's email address. For Conga IDP users, this is also what they use to log in. If multiple accounts share the same email address, the most recently created account becomes the primary. | |
| Username | For Conga IDP users: auto-populated from the Email field. Can be customized to create an email alias (e.g., [email protected]) if multiple accounts share the same email. For Salesforce IDP and other external IDP users: enter a username for informational purposes only - it is not used for authentication. |
| Role | The role controlling the user's permissions on the Platform. See Roles and Permissions for guidance on which role to assign. |
| External ID | Maps the user to an external system for data sync and authentication. For Salesforce IDP users: enter the user's Salesforce User ID. For Conga IDP users: enter any unique identifier. |
| Fields | Description |
|---|---|
| Federation ID | Maps the user to a federated authentication system (SAML 2.0 or OpenID Connect). Only required if you are using a separate IDP specifically for authentication that is not Salesforce, Salesforce Sandbox, or Microsoft Dynamics 365. If using the Conga IDP, this can be set to any value. |
| Permission Groups | Additional permission groups beyond what the assigned role provides. For most Sign users, the role alone is sufficient to provide Conga Sign Permissions. See Section 2.4. |
| Organization External ID | The IDP connection to associate this user with. Defaults to your organization's default IDP. Only change this if the user should authenticate through a different IDP than your default. |
| Timezone | The user's timezone. If left blank, the organization's timezone is used. Affects transaction expiration date calculations. |
| Preferred Locale | The user's locale for formatting dates, numbers, and currency. If left blank, the organization's locale is used. Only displays locales enabled at the organization level. |
| Currency | The user's default currency. If left blank, the organization's currency is used. |
| Alias | A short display name for the user. Optional. |
| Language | The user's language code (e.g., en-US). Optional. |
| Address | The user's address. Optional. |
| Phone Number | The user's phone number. Optional. |
Roles and Permissions
Roles are the primary mechanism for controlling what a user can access and do on the Platform. Choosing the right role at user creation is the single most important step in getting Sign access working correctly.
| User Type | Recommended Role | What It Provides |
|---|---|---|
| Admins who will configure Sign settings | Admin | Full Platform access and Document Management Application access. Includes all necessary Sign object permissions by default. |
| Standard Sign users (senders) | Cloned Conga Sign Integration User | Access to send transactions and interact with Sign. Automatically includes the Conga Sign Permissions group. Cloning the Conga Sign Integration User role allows additional permissions to be granted beyond what the standard role provides, without modifying the base role itself. |
| Auto-provisioned users | AuthAutoProvisionedUser | Limited access by design. Must be updated before users can access Sign - see below. |
| Dedicated Salesforce connector user | Conga Sign Integration User | Same as standard Sign users; appropriate for the system account holding the connector authentication. |
A role is a bundle of permissions. For Sign specifically, having the right role means:
The user can see the Document Management Application in the Platform.
The user has read/write access to the underlying Sign objects that power transaction processing.
The user can initiate and manage transactions based on their role level.
Without the right role (or the Conga Sign Permissions group for auto-provisioned users), a user may be able to log in to the Platform but will hit a wall when trying to access anything Sign-related.
Updating the AuthAutoProvisionedUser Role
Auto-provisioned users land with the AuthAutoProvisionedUser role, which is intentionally minimal. Before they can access Sign, update the role as follows:
Navigate to Admin Console → Users → Roles tab.
Open the AuthAutoProvisionedUser role and click Edit.
In the Permissions Group dropdown, select Conga Sign Permissions.
In the Admin Permissions dropdown, select View Document Management Application.
- Click Save.Attention: This change applies to all auto-provisioned users in your organization. If some auto-provisioned users should not have Sign access, create a separate role for them rather than modifying this default.
Granting Manager Rights
Manager Rights allow a Sign user to configure settings within the Conga Sign application - account-level settings, template management, and user administration within Sign. A user without Manager Rights can still send transactions but cannot make administrative changes inside Sign Settings.
To grant Manager Rights:
Navigate to Document Management Apps → Sign Settings → User Management tab.
Locate the user and click the three-dot menu next to their name.
- Select Grant Manager Rights.Attention: Grant Manager Rights to any admin responsible for configuring Sign, managing account-level templates, or onboarding other users. Standard senders do not need this.
Giving Access to Sign
Creating a Platform user and assigning a role gets them into the Platform. To make them a Sign user specifically - visible in Sign's own user management and able to be assigned as a sender - they also need to be added within Sign Settings.
This happens automatically when a user is assigned a role that includes both the View Document Management Application admin permission and the Conga Sign Permissions permission group (such as the Conga Sign Integration User role). If the automatic assignment does not occur, or if you need to add a user manually, follow these steps:
Navigate to
Click Invite New Sender.
Search for the user and select them to add them.
Refer to Account Settings: User Management below for full details on this
Conga Sign Settings
Once users are set up, Sign Settings is where administrators configure how Sign behaves for their entire organization. Navigate to to access it.
Sign Settings is organized into three groups in the left navigation:
Account Settings - organization-wide configuration for your Sign account
General Settings - behavior settings for emails, features, and transactions
Connector Settings - Salesforce data mapping and connection management
The following sections walk through each area.
Account Settings: Business Identity
Business Identity controls how your organization appears to recipients during the signing experience.
Company Logo
Upload your organization's logo to display it in signing invitations and the signing interface. Supported formats are JPEG, PNG, GIF, BMP, and SVG. Maximum file size is 1 MB. Recommended dimensions are 258 px by 40 px.
Colors
Define the colors that recipients see during signing. There are three color categories:
Branding - Primary: The main brand color used throughout the signing experience (buttons, highlights, headers). Accepts a hex value.
Alerts: Four alert state colors - Success, Warning, Error, and Info. These control the color of status messages recipients see during signing. Defaults are standard green/amber/red/blue.
- Signatures - Required Signature Button / Optional Signature Button: The colors of the signature field buttons as they appear to the recipient. Using visually distinct colors for required vs. optional fields can help recipients understand what they must complete.Attention:
Click Reset Defaults to restore all color values to the Conga defaults at any time
Account Settings: Data Retention
| Setting | What it Controls |
|---|---|
| Total Transaction Lifetime | The maximum number of days any transaction can exist in the system, regardless of status. Acts as a hard ceiling over all other limits. This value can only be updated by contacting Conga Support and is intended to serve as a reference point for your organization's overall retention ceiling. |
| Archived Transactions | How long archived transactions are retained. |
| Incomplete Transactions | How long transactions that have not been completed are retained. Default: 120 days. |
| Completed Transactions | How long completed (fully signed) transactions are retained. |
| Draft Transactions | How long draft transactions are retained. |
| Sent Transactions | How long sent (awaiting signature) transactions are retained. |
| Declined Transactions | How long declined transactions are retained. |
| Expired Transactions | How long expired transactions are retained. |
Each setting has a Days input and an Unlimited checkbox. When Unlimited is checked, transactions in that state are never automatically deleted. Uncheck Unlimited and enter a number to set a specific limit.
Documents are permanently deleted when the retention period is reached. There is no recycle bin and deletion is not recoverable. If your organization has compliance, legal hold, or records retention requirements, coordinate with your legal team before configuring these values - and consider whether signed documents need to be exported or stored in an external system before deletion occurs.
Account Settings: Sent Transaction Expiry Time
Sent Transaction Expiry Time sets the account-level defaults for how long a sent transaction stays open before it automatically expires.
| Setting | What It Controls |
|---|---|
| Default | How many days after sending a transaction expires. This is the organization-wide default applied to all transactions unless overridden at the transaction level. |
| Maximum | The maximum number of additional days a sender can extend a transaction's expiration date beyond the default. For example, if Default is 30 days and Maximum is 10, a sender can push the expiration up to 40 days. |
The Templates page is the central library for all Sign templates in your organization. From here, admins can view, search, create, edit, and manage all account-level templates. See Section 3 for full template configuration guidance.
Account Settings: Usage
The Usage page under Sign Settings currently displays a single metric - Transactions Used (12 Months) - showing the total number of transactions initiated across your organization in the past rolling year.
For more meaningful usage data, navigate to instead. This report provides a richer view including:
Sign Transactions Used - transaction volume over time
Document Usage - total document count
Daily Transaction Usage - a day-by-day trend chart
Usage by Type - a breakdown of usage by document type
Sign Transactions - a full transaction-level detail table
Account Settings: User Management
The User Management tab within Sign Settings is distinct from user management in the Admin Console. This is where administrators manage Sign-specific user settings - including granting and revoking Manager Rights - for users who have already been created as Platform users.
The User Management tab shows all users who have been added as Sign senders in your organization. It only shows users who are active within Sign itself - it does not reflect the full Admin Console user list.
| Role | Description |
|---|---|
| Owner | The account owner. Typically the first admin who set up the Sign account. |
| Manager | Users who have been granted Manager Rights and can configure Sign Settings. |
| Member | Standard senders. Can send and manage their own transactions but cannot change Sign Settings. |
Grant Manager Rights - promotes the user from Member to Manager.
Lock Sender - prevents the user from sending new transactions without removing them from the system.
Delete Sender - removes the user from Sign. This does not delete their Platform user account.
Email Reminder Settings lets you configure an organization-wide default schedule for sending automatic reminder emails to recipients who haven't yet completed signing.
Send Email Reminders
When enabled, the system sends a reminder email to all recipients who have not yet completed signing. You configure how many days after the transaction is sent the first reminder goes out (1–1000 days).
Repeat Reminders
When enabled (requires Send Email Reminders to be on), the system sends additional reminders on a repeating schedule after the first. Configure:
Every - how many days between repeated reminders (1–1000)
Ends after - the total number of additional reminders to send (1–5)
Click Reset to restore the defaults, or Save to apply your changes.
General Settings: Feature Settings
Feature Settings controls which capabilities are available to senders and recipients across your entire organization. Settings are grouped into six collapsible sections.
General
| Setting | Description |
|---|---|
| Override Recipient's Preferred Language | Allows senders to specify a display language for any recipient before sending. |
| Disable Footer | Hides the application footer within the sender interface. |
Authentication
| Setting | Description |
|---|---|
| Enable Q&A Authentication | Makes Q&A Authentication available as a recipient authentication method. When enabled, senders can configure challenge questions recipients must answer before signing. |
| Mask Recipient Answers During Q&A Authentication | Sets the default value of the "Mask response" toggle for Q&A Authentication. Senders can override this on a per-transaction basis. |
| Require Recipient Authentication | When enabled, every recipient in a transaction must be assigned an authentication method. Transactions cannot be sent unless all recipients have an authentication method configured. |
Document Preparation
| Setting | Description |
|---|---|
| Enable Optional Signatures | Allows signature fields to be flagged as optional, so recipients are not required to complete every signature before finishing. |
| Enable Conditional Fields | Enables the configuration of conditional fields in templates and transactions. |
| Enable Document Visibility | Gives senders the ability to control which recipients can see specific documents during the signing ceremony. |
| Disable Removal of Electronic Consent Document | Prevents senders from removing the Electronic Consent document from templates or transactions. |
| Enable Recipient to Upload Attachment | Allows recipients to upload attachments during signing. Senders can then request file uploads from recipients as part of the transaction. |
| Enable Imprint Fields | Enables imprint fields in document preparation. |
Document Security
| Setting | Description |
|---|---|
| Flatten Documents for Recipients | When enabled, documents downloaded or emailed to recipients are always flattened (read-only). When disabled, documents are flattened only if the transaction is incomplete; completed transaction documents remain active. |
Email Documents
| Setting | Description |
|---|---|
| Email Signed Documents and Evidence Summary | When enabled, signed documents and the Evidence Summary are automatically emailed to the transaction owner on completion. |
| Email Evidence Summary | When enabled, the Evidence Summary alone is emailed to the transaction owner on completion. |
| Allow Document Delivery for Transaction Recipients | When enabled, senders have the option to deliver signed documents to signers as email attachments. |
In-Person Signing
| Setting | Description |
|---|---|
| Disable Sending Signing Invitation Email to Recipients within an In-Person Signing Transaction | When enabled, recipients in an in-person signing transaction do not receive an email invitation to sign. This is appropriate when the signing will be completed on a shared device in person rather than remotely. |
| Allow Account Senders to Host In-Person Signing Transactions | When enabled, any sender within the account who is also a recipient on an in-person transaction can host that transaction. When disabled, only the transaction owner can host. |
Signing
| Setting | Description |
|---|---|
| Add Checkbox to the Top of the Consent Document | When enabled, signers can accept the Electronic Consent Document via a checkbox at the top of the page. When disabled, they can only accept via the button at the bottom. |
| Enable Transactions to be Sent to Mobile Devices | Allows transactions to be sent to mobile devices. |
| Enable the 'Mobile Signature' Type | Makes the Mobile Signature type available during document preparation. The recipient receives an email link to open the document on their phone and draws their signature with a finger or stylus. |
| Enable Signing via an Uploaded Image | Allows signers to apply their signature by uploading an image. |
General Settings: Transaction Settings
Transaction Settings controls how the signing experience is presented to recipients and what options are available to senders. Settings are grouped into six collapsible sections.
General
| Setting | Description |
|---|---|
| Hide Language Dropdown | Removes the Language option from the More Actions menu in the signer experience. |
| Expand Documents Panel by Default | When enabled, the Documents panel is expanded when a recipient opens the signing ceremony. Recipients can still toggle it manually. Does not apply to tablet or mobile devices. |
| Display Help Menu | Shows or hides the Help option in the More Actions menu of the signer experience. |
| Display Overview Page to Recipient | When enabled, recipients see an Overview page when they access the signing ceremony, listing the documents they need to sign and any supporting documents they need to upload. |
| Display Signing Logo within iFrames | Controls whether the signing logo is shown when the signing experience is displayed within an iFrame. |
| Geolocation | When enabled, geolocation data is gathered and included in the Evidence Summary. Requires signer consent. |
| Display Document Name on Each Page | Shows the document name at the bottom of each page in the signer experience. |
| Display Signing Progress | Shows a signing progress indicator to recipients during the signing ceremony. |
| Allow Recipient to Navigate Across Actionable Fields | Displays a field navigator in the signer experience to help recipients move through all required fields. |
| Include Optional Fields in Navigation | When enabled, the field navigator also navigates through optional fields, not just required ones. |
Declining to Sign
| Setting | Description |
|---|---|
| Allow Recipient to Decline Transaction Signing | When enabled, recipients see a Decline option in the More Actions menu during signing. |
| Disable 'Decline: Other' | When enabled, removes the free-text "Other" reason option from the decline flow. If no custom decline reasons have been configured (done via Support), this setting has no effect. |
Global Actions
| Setting | Description |
|---|---|
| Display 'Download' Button | Shows the Download button in both the signing ceremony and the transaction page of the sender interface. Applies to transaction owners and recipients during signing. Note: Transaction owners can always download their own transaction documents regardless of this setting. |
| Disable Document Download for Incomplete Transactions | Prevents recipients from downloading documents before the transaction has been completed. |
| Hide Evidence Summary | When enabled, the Evidence Summary is not available for download by the transaction owner after completion. |
In-Person Configuration
| Setting | Description |
|---|---|
| Hide Transaction Owner from Recipients List in an In-Person Transaction | When enabled, the transaction owner is not shown in the recipients dropdown on the Welcome page of an in-person signing ceremony, even if they have signatures on the transaction. |
Sender
| Setting | Description |
|---|---|
| Enable Document Extraction when Uploading Documents | When enabled, Adobe Acrobat form fields are automatically extracted when a document is uploaded to a transaction. |
| Enable Text Tag Extraction when Uploading Documents | When enabled, text tags embedded in documents are automatically extracted on upload. This is the setting that makes text-tag-based field placement work without manual tagging in the editor. |
| Enable Transaction Expiry in Days | When enabled, the default expiry type is set to a number of days. When disabled, expiry is defined as a specific date. Senders can override this when creating a template or transaction. |
| Enable In-Person Signing for all New Transactions | When enabled, all newly created templates and transactions default to In-Person signing type. Senders can override this per template or transaction. |
| Enable Screen-Reader Accessibility for all New Transactions | When enabled, screen-reader accessibility is on by default for all new templates and transactions. Senders can override this per template or transaction. |
| Limit Number of Files per Attachment | Sets a maximum number of files a signer can upload per attachment field. Set to 0 for unlimited. |
| Font Size | Sets the default font size for signatures and form fields displayed on documents. Set to Auto-fit to have fields scale automatically. |
Signature Settings
| Setting | Description |
|---|---|
| Hide Signature Details for Handwritten Signatures | When enabled, the signature details (name, date, etc.) are not displayed behind the handwritten signature on a signed document. |
| Require Signer to Draw their Signature for Each Hand-Written Signature | When enabled, signers must draw their handwritten signature each time they click a handwritten signature box, rather than having it auto-applied from a saved signature. |
| TimeStamp on Signature | When enabled, shows a timestamp on a signature that has been placed but not yet confirmed by the signer. |
Click Reset to restore Transaction Settings to their defaults, or Save to apply changes.
Data Mapping is where administrators configure which Salesforce fields can be pre-filled into signing tags or written back to Salesforce when a transaction completes. The Mapped Data Tags list shows all configured mappings, with columns for:
Active - whether the mapping is currently enabled and available for use in templates and transactions
Write Back to Field - whether the signer's input is synced back to the Salesforce field on completion
Insert Field Value - whether the Salesforce field value is pre-populated into the signing tag when the transaction is created
Target Platform - the connected source system (e.g., Salesforce)
Target Object - the Salesforce object the field belongs to (e.g., Opportunity, Account)
Target Field - the specific field being mapped
Click New Data Mapping to create a new mapping. Select the Target Source, Target Object, and Target Field, then toggle Insert Field Value from Source and/or Write Back to Source Field as needed. Use Add Another to create up to 5 mappings in a single save operation.
Existing mappings can be Edited or Deleted via the three-dot menu on each row. Editing opens an Update Data Mapping dialog where you can change the field selection and toggle the Active state without having to delete and recreate the mapping.
Connector Settings: Data Sync Connections
Data Sync Connections is where you establish and monitor the live connection between Conga Sign and Salesforce. The page lists available providers with their connection status, the email address of the user who authorized the connection, and a Connect or Disconnect action.
A green Connected status with a user email shown means the connection is active. The connection is tied to the specific Salesforce user who authorized it - this should always be your dedicated connector user, not a personal admin account.
SAML 2.0 Single Sign-On (SSO) Configuration
When your organization uses an enterprise identity provider (IdP) such as Microsoft Entra (Azure AD), Salesforce, or Okta, you can configure SAML 2.0 as the authentication method for the Conga Advantage Platform. In this model, the Platform acts as the Service Provider (SP) and redirects login requests to your IdP. Once users authenticate successfully, the IdP returns a SAML assertion to the Platform to establish their session - eliminating the need for a separate Platform password.
Platform user accounts are tied to the IDP they were created under. A user provisioned under the Conga IDP cannot simply be reassigned to a SAML IdP - the two accounts are separate and cannot be merged.
This comes up most often with administrators. If you were originally provisioned with a Conga IDP account to set up and configure the Platform, and your organization is now switching to Microsoft Entra, Salesforce SAML, or Okta for SSO, you will need a new Platform user account created under the SAML IdP before you can log in via SSO. Your original Conga IDP account continues to exist independently and can still be used if needed.
Choose your Identity Provider:
Microsoft Entra (Azure AD)
Salesforce as a SAML IdP
Okta
Common field reference - Add New External Integration form
| Field | Description |
|---|---|
| Download SP Metadata File | Downloads the Platform's Service Provider metadata XML. Use this file when registering the application in your IdP if your IdP supports metadata file upload. |
| Choose IDP Metadata Setup | How you supply the IdP's metadata to the Platform. Select URL Input to paste the IdP's metadata URL, or XML File Upload to upload the metadata file directly. |
| External Organization ID | The unique identifier that maps this integration to your organization in the IdP. The specific value varies by provider - see each section below. |
| Type | A free-form label for this integration (e.g., Prod, UAT, Dev). For informational purposes only. |
| Organization ID Claim Type | A URI identifying the SAML claim that carries the organization ID. Required for Microsoft Entra; leave blank for Salesforce and Okta. |
| Description | Optional description. |
| Email Domain | The email domain to associate with this IdP. Used for routing and administrative purposes. |
| Display Name | The display name for this IdP as it appears in the Platform. |
| Default IDP | When enabled, all new Platform users are created under this IdP by default. Enable this for your primary SSO provider. |
Microsoft Entra (Azure AD) as a SAML Identity Provider
Microsoft Entra acts as the IdP; the Conga Advantage Platform acts as the SP. Setup requires registering a non-gallery enterprise application in the Entra portal, uploading the Platform's SP metadata, and then collecting the Tenant ID and metadata URL to configure the integration on the Platform side.
Step 1: Register an application in Microsoft Entra (These steps are performed by your Microsoft Entra / Azure AD administrator.)
Log in to portal.azure.com.
Select Microsoft Entra ID and go to Enterprise Applications.
Click New Application, then click Create your own application.
Enter an app name.
Select Integrate any other application you don't find in the gallery (Non-gallery).
Click Create.
Open the registered app, go to Single Sign-on, and select SAML.
Click Upload metadata file and upload the SP metadata file. You can download the SP metadata file from one of the following URLs (use the URL matching your region) or from the Download SP Metadata File button on the Add New External Integration screen (Step 3):
Region SP Metadata URL NA https://login.congacloud.com/api/v1/auth/Saml2 EU https://login.congacloud.eu/api/v1/auth/Saml2 AU https://login.congacloud.au/api/v1/auth/Saml2 After uploading, the Basic SAML Configuration fields are auto-filled from the metadata. Click Save, then Done.
Step 2: Collect the Tenant ID, Metadata URL, and Organization ID Claim Type
In Enterprise Applications, open the registered app and go to Single Sign-on → SAML 2.0.
Under SAML Certificate, copy the App Federation Metadata Url - this is your Metadata Location URL.
Open that URL in a browser.
External Organization ID: Find the entityId attribute in the root XML node. Copy the GUID at the end of the URL - that is your Tenant ID. For example, if entityId is https://sts.windows.net/8831e6d9-dc6c-4cd1-9cc6-1dc2d4133195/, the Tenant ID is 8831e6d9-dc6c-4cd1-9cc6-1dc2d4133195.
Organization ID Claim Type: Search the XML for tenantid. If found, use the URI attribute of that XML tag as the Organization ID Claim Type (e.g., http://schemas.microsoft.com/identity/claims/tenantid). If not found, leave the field blank.
Step 3: Add Microsoft Entra as an external integration in the Platform
Log in to the Conga Advantage Platform as an administrator.
Navigate to
Click Add New and select SAML 2.0.
- Complete the form using the values collected in Step 2:
Field Value Choose IDP Metadata Setup Select URL Input and paste the App Federation Metadata Url from Step 2. Alternatively, select XML File Upload and upload the metadata XML. External Organization ID The Tenant ID (GUID) extracted from the entityId in Step 2. Organization ID Claim Type The tenantid URI from Step 2, or blank if not found. Type Enter a label such as Prod. Default IDP Enable if this should be the default authentication method for new users. Click Save
Step 4: (optional): Configure IdP-initiated SSO flow
If you want users to be able to launch the Platform directly from the Entra portal or a bookmark, configure the following additional attributes in the Entra app:
In the Entra portal, go to the registered app .
- Add the following two attributes:
redirect_url values:Attribute Value redirect_url The Platform URL for your environment (see table below). client_id The SPA Client ID for your environment (see table below).
client_id values:Environment Region URL Production NA Production EU Production AU Preview / Sandbox NA Preview / Sandbox EU Preview / Sandbox AU Environment Region Client ID Production NA rls-prod-spa Production EU rls-prodeu-spa Production AU rls-prodau-spa Preview / Sandbox NA rls-preview-spa Preview / Sandbox EU rls-previeweu-spa Preview / Sandbox AU rls-previewau-spa Click Save.
Salesforce as a SAML Identity Provider
This path uses Salesforce as the SAML IdP rather than using the standard Salesforce IDP OAuth flow described in Setting up a Salesforce IDP Record. Use this approach when your organization requires SAML-based federated authentication and is not using the Salesforce IDP OAuth connection.
These configuration steps in Salesforce require System Administrator access.
Step 1: Enable the Salesforce Identity Provider
Log in to Salesforce.
Go to .
Click Enable Identity Provider.
Select a self-signed certificate from the dropdown.
Click Save.
Step 2: Enable SAML Single Sign-On
In Setup, search for and select Single Sign-On Settings.
Click Edit.
Check the SAML Enabled checkbox.
Click Save.
Step 3: Create a SAML-enabled Connected App
In Setup, search for External Client Apps and select Settings.
Under Connected Apps, enable Allow creation of connected apps.
- Click New Connected App and complete the Basic Information section:
Field Description Connected App Name A display name for the app as it appears in the App Manager. API Name Auto-generated from the app name. Contact Email Email of the admin managing this connected app. - In the Web App Settings section, configure the following fields and leave all others as-is:
Entity Id and ACS URL by environment:Field Description Enable SAML Check this checkbox. Entity Id The Platform's globally unique SP identifier. Use the URL for your environment (see table below). ACS URL The Assertion Consumer Service endpoint. Use the URL for your environment (see table below). Name ID Format Email address. Signing Algorithm for SAML Messages SHA256. Click Save.
Open the connected app, click Edit Policies, and in the Custom Attributes section add an attribute with:
Key: external_organization_id
Value: Your Salesforce Organization ID
Click Save.
In the User Accounts section, add the users who should have access.
In the Profiles and Permission Sets sections, assign the appropriate profiles/permission sets.
Step 4: Collect the Metadata URL
In Setup, search for and select Manage Connected Apps.
Open the connected app created in Step 3.
Go to the SAML Login Information section.
- Copy the Metadata Discovery Endpoint - this is your Metadata Location URL.Note: To use the standard Salesforce org as the SSO source, use the org's Metadata Discovery Endpoint. To use a Salesforce Community as the SSO source, use the Community's Metadata Discovery Endpoint instead.
Step 5: Add Salesforce as an external integration in the Platform
Log in to the Conga Advantage Platform as an administrator.
Navigate to .
Click Add New and select SAML 2.0.
- Complete the form:
Field Value Choose IDP Metadata Setup Select URL Input and paste the Metadata Discovery Endpoint from Step 4. External Organization ID Your 18-digit Salesforce Organization ID. Organization ID Claim Type Leave blank. Type Enter a label such as Prod. Default IDP Enable if this should be the default authentication method for new users. Click Save.
Okta as a SAML Identity Provider
Step 1: Create a SAML application in Okta
Log in to Okta.
In the Admin Console, go to .
Click Create App Integration.
Select SAML 2.0 as the sign-in method and click Next.
Provide a name for the integration and click Next.
In the General section, configure the following:
Single sign-on URL (ACS Endpoint): Enter the URL for your region and check Use this for the Recipient URL and Destination URL.
Region ACS URL NA https://login.congacloud.com/api/v1/auth/Saml2/Acs
Region ACS URLEU https://login.congacloud.eu/api/v1/auth/Saml2/Acs
Region ACS URLAU https://login.congacloud.au/api/v1/auth/Saml2/Acs
Audience URI (SP Entity ID): Enter the URL for your region.
Region Audience URI NA https://login.congacloud.com/api/v1/auth
Region Audience URI EU https://login.congacloud.eu/api/v1/auth
Region Audience URI AU https://login.congacloud.au/api/v1/auth
Name ID format: Select Email address.
In the Advanced Settings section, configure the following:
Attribute Statements: Add an attribute with Name external_organization_id and a value equal to the unique external ID you'll use when registering this integration on the Platform.
SAML Request (signature certificate): Click Browse files and upload a .CER signature certificate. To generate it:
Download the SP metadata file from the URL for your region (or from the Download SP Metadata File button on the Platform's Add New External Integration screen):
Region SP Metadata URL NA https://login.congacloud.com/api/v1/auth/Saml2
Region SP Metadata URL EU https://login.congacloud.eu/api/v1/auth/Saml2
Region SP Metadata URL AU https://login.congacloud.au/api/v1/auth/Saml2
Open the metadata XML and find the Base64-encoded X.509 certificate.
Convert the Base64 value to .CER format using https://www.samltool.com/format_x509cert.php .
Save the result (including the header line) with a .cer extension and upload it.
Log Out: Check Allow app to initiate single logout.
Response URL: Use the URL for your region: Region SLO Response URL NA https://login.congacloud.com/api/v1/auth/account/SamlLogout
Region SLO Response URL EU https://login.congacloud.eu/api/v1/auth/account/SamlLogout
Region SLO Response URL AU https://login.congacloud.au/api/v1/auth/account/SamlLogout
SP Issuer: Use the Audience URI for your region (same as Step 6b).
Click Save.
Step 2: Collect the Metadata URL and External Organization ID
Open the application in Okta and go to the Sign On tab.
In the SAML 2.0 section, copy the Metadata URL - this is your Metadata Location URL.
Go to the General tab and open the Attribute Statements section.
- Copy the value of the external_organization_id attribute - this is your External Organization ID.Note: Alternatively, you can use your Okta Org ID as the External Organization ID. See How to Find the Okta OrgId in Okta Support.
Step 3: Add Okta as an external integration in the Platform
Log in to the Conga Advantage Platform as an administrator.
Navigate to .
Click Add New and select SAML 2.0.
- Complete the form using values from Step 2:
Field Value Download SP Metadata File Use this if you haven't yet downloaded the SP metadata file for Step 1. Choose IDP Metadata Setup Select URL Input and paste the Metadata URL from Step 2. External Organization ID The external_organization_id value from Step 2 (or your Okta Org ID). Organization ID Claim Type Leave blank. Type Enter a label such as Prod. Default IDP Enable if this should be the default authentication method for new users. Click Save.
Step 4 (optional): Configure IdP-initiated SSO flow
In Okta, open the application and go to the .
- Add the following two attributes:
Attribute Value redirect_uri The Platform URL for your environment. client_id The SPA Client ID for your environment. Click Save.