Skip to main content
Connect Close to Oleria to see who and what can act on your Close organization: its users and the roles and groups that grant their access, the webhook subscriptions that receive its data, the API key Oleria connects with, and the governance events in Close’s event log. Oleria connects with a Close API key, and can also deactivate, reactivate, and add users, change a user’s role, add and remove users in groups, create groups, and pause webhook subscriptions.
Each integration connects one Close organization. If you have more than one, add an integration for each. See Multi-instance support.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Close organization:
  • Users - every member of the organization, active and deactivated, with name, email, and role. Oleria also shows:
    • Status - active members are shown as enabled, and deactivated members as disabled.
    • Administrator status - users whose role grants Manage Groups, Users, Billing & Roles/Permissions (manage_organization) are marked as administrators.
    • API access - users whose role lets them create their own API keys (manage_own_api_keys) are marked as having API access.
    • MFA - from each user’s two-factor authentication (2FA) enrollment. Close 2FA uses an authenticator app (TOTP). A user who has turned on 2FA shows MFA as required, a user who hasn’t shows MFA as not required, and any other 2FA state shows MFA as unavailable.
    • Last activity - the time of the user’s newest entry in Close’s event log in the last 30 days. This is the user’s last data change, not their last login. See Known limitations.
    • Creation date - when the Close user was created. Close doesn’t report when the user joined your organization.
  • Roles - every role in the organization. Each user holds exactly one role. Close’s built-in Admin, Super User, User, and Restricted User roles are marked as standard roles, and roles you can edit as custom roles. Each role’s permissions are shown as entitlements, grouped by area, such as organization administration, API access, data export and bulk actions, and lead data. A role that restricts which leads its users can see says so in its description. A role that appears on a user but isn’t in Close’s role list is also shown, with that user’s permissions.
  • Groups - every group, with its members. Close groups are flat and don’t hold roles. A deactivated user who is still in a group keeps that membership. Groups need the Close Scale plan or above.
  • Non-human identities (NHIs):
  • Activity - governance events from Close’s event log:
    • users added to or deactivated in the organization;
    • groups created, changed, or deleted;
    • lead and opportunity exports, when requested and when completed;
    • bulk deletes, bulk edits, bulk emails, and bulk sequence subscriptions, when started and when completed;
    • imports started, completed, or reverted;
    • configuration changes: custom fields, custom activity types, custom object types, and lead and opportunity statuses created, updated, or deleted.
    Every event keeps its Close event name. Events are attributed to the Close user who made them. An event made by someone who isn’t an active or deactivated member of the organization, such as Close staff using Close Support Access or a user who was removed from the organization, has no actor account in Oleria and keeps that person’s Close user ID. Events with no user, such as Close system events, are skipped. An event made with any other API key is marked as made with a token, and keeps that key’s ID. An event made with this integration’s own API key is attributed to the API key NHI, acting as its user. Oleria doesn’t import the changed records’ contents.
Oleria refreshes this data on its regular sync schedule.
This integration covers users, roles, groups, NHIs, and activity. It doesn’t sync CRM records such as leads, contacts, opportunities, activities, tasks, or custom objects, so Oleria doesn’t populate resource-level Access Graph or Access Inventory data for Close. It also doesn’t discover connected email and calendar accounts, or Send As delegations.

​
Prerequisites

  • A Close user for Oleria whose role grants Manage Groups, Users, Billing & Roles/Permissions (manage_organization), such as Close’s built-in Admin role. A dedicated integration user is best. See Permissions for reading for what Oleria reads without it.
  • An API key created by that user. See Create the Oleria credential in Close.
  • For groups and custom roles, the Close Scale plan or above. On other plans, Oleria discovers no groups.
  • Admin access on the Oleria platform to add a new integration.
Use a dedicated Close user for Oleria rather than a person’s account. A Close API key belongs to the user who created it, acts with that user’s role, and never expires. If that user is deactivated or removed from the organization, the key stops working and syncs fail.
Close API keys have no scopes, so there’s no read-only key. The key can do anything its user’s role allows, including changing users and roles. Oleria uses the same key for remediation actions, so store it securely.

​
Create the Oleria credential in Close

1

Choose the Close user

Pick the Close user Oleria will connect as, ideally a dedicated integration user. Give that user a role that grants Manage Groups, Users, Billing & Roles/Permissions, such as Admin.The tables below show what each permission is used for.
2

Create an API key

Sign in to Close as that user, go to Settings > Developer > API Keys, and create an API key. Copy the key. You enter it as API key when you connect.
3

Find the organization ID (only if needed)

If the user belongs to more than one Close organization, note the ID of the one to connect. It starts with orga_ and is shown under Settings > Organization. If the user belongs to one organization, skip this step.

​
Permissions for reading

​
Permissions for remediation actions

Remediation actions are optional. Every action needs Manage Groups, Users, Billing & Roles/Permissions (manage_organization) on the key’s user. Without it, Oleria refuses every action.

​
Connect Close to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Close.
2

Complete the connection form

3

Authenticate

Select Authenticate. Before it saves anything, Oleria checks the key with Close, finds the organization, and reads it. If the key’s user lacks Manage Groups, Users, Billing & Roles/Permissions, Oleria still connects, but reads less, as described in Permissions for reading, and refuses every remediation action.Find the newly connected organization on the Connected tab of your Oleria Integrations page, named Close (organization name).
If Authenticate fails, the message says what’s wrong:
  • Close rejected the API key (HTTP 401) - the key is invalid or was deleted, or its user was removed from the organization. Create a new key and try again.
  • Close denied access (HTTP 403) - Close refused the key. Check that the key’s user is an active member of the organization.
  • The API key’s user belongs to several organizations - enter the Organization ID of the organization to connect.
  • The API key’s user is not a member of organization … - the Organization ID doesn’t match any organization the key’s user belongs to. Check the ID, or leave it blank if the user belongs to one organization.
  • Close did not find the organization (HTTP 404) - check the Organization ID.
  • The API key’s user belongs to no organization - use a key created by a member of the organization you want to connect.
  • Close could not be reached - Close didn’t respond. Try again in a few minutes.
  • Connection validation failed (HTTP …) - Close returned an unexpected error. Try again. If it persists, contact support@oleria.com.

​
Edit the integration

When you edit the integration, you can change API key. Organization ID (optional) can’t be changed. To connect a different organization, add a new integration.
  • Leave API key blank to keep the stored key.
  • A new key must belong to the same Close organization. Otherwise, Oleria refuses it with This API key belongs to Close organization …, but the integration is connected to ….
Select Update to save. Oleria runs the same checks as Authenticate.

​
Verify the integration

Confirm the organization appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, review the discovered users, roles, groups, NHIs, and activity in your Oleria workspace. In the integration’s Capabilities and operation readiness section, Read users, Read groups, and Read roles show Available. If one shows Needs permission, Close refused the key. Check that the key’s user is still an active member of the organization. If no groups appear, check that your Close plan includes groups. If webhook subscriptions are missing, check that the key’s user has Manage Groups, Users, Billing & Roles/Permissions. If no activity or last activity appears, the key’s user has neither that permission nor view_all_leads.

​
Remediation actions

Oleria can take these actions in Close:
The Remediations page offers Revert only for Disable user accounts, Remove user from group, and Disable NHI accounts. The integration supports the other reverts in this table, but the Remediations page doesn’t offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed.
Keep these limits in mind when you use these actions:
  • Oleria refuses to deactivate, or change the role of, the Close user who owns the integration’s API key. It also refuses to deactivate the organization’s last user with Manage Groups, Users, Billing & Roles/Permissions, or to give that user a role without it.
  • Enable user accounts, Create user, and the Disable user accounts revert add a member through Close’s API. Close accepts this only when Restrict new users to emails from these domains is on and the email is on one of your verified domains. Otherwise, Close refuses, and the message says so. For a role that grants Manage Groups, Users, Billing & Roles/Permissions, see the Disable user accounts revert above.
  • Create user makes no change if an active user with that email already exists. If a deactivated user has that email, it fails. Use Enable user accounts for them instead.
  • Remove user from role can’t remove Restricted User, because the user would have no role.
  • Add user to role works only with a role that exists in the organization.
  • Every action reads the current state first. If the user, group, or subscription is already in the state the action asks for, Oleria makes no change. After a change, Oleria reads it back from Close, and the action fails if the change isn’t there.
  • Oleria sends Create user and Create group only once. If Close doesn’t answer, Oleria checks for the new user or group. If it now exists, the action succeeds.
  • Reverting an action changes only what the action changed. If the target changed since the action, for example the user’s role changed again or the group gained members, the revert makes no change and says why.
  • Group actions need the Close Scale plan or above. On other plans, Close refuses them and the action fails.

​
Known limitations

  • No SSO or security settings. Close’s API doesn’t report your single sign-on (SSO) configuration or enforcement, whether 2FA is enforced for the organization, trusted email domains, or Close Support Access. Users show SSO as unavailable, and MFA reflects only each user’s own 2FA enrollment.
  • No login history. Close’s API has no login history, last login, or last password change. Oleria’s last activity is the user’s newest event-log entry, which is their last data change. Users who only read data, and deactivated users, show no last activity.
  • 30 days of activity. Close keeps its event log for 30 days, so Oleria can’t read older activity, and a user with no event in that time shows no last activity. Close’s event log has no sign-in, role change, API key, or webhook events, so those changes don’t appear as activity. Oleria doesn’t import events about CRM records, saved searches, phone numbers, email templates, or sequences. Events from the last five minutes are read on the next sync. Close can still update an event for a few minutes after it happens, so each sync also reads the five minutes before its window again.
  • Some actions aren’t in Close’s API. Close’s API can deactivate a user but not delete one, and can’t end a user’s sessions or reset their 2FA. Oleria doesn’t offer Delete user or Revoke sessions for Close. Permissions belong to roles, so Oleria doesn’t offer application or entitlement assignment.
  • Other API keys and apps aren’t listed. Close’s API lists neither other users’ API keys nor the OAuth apps and integrations users have authorized. Oleria shows only its own API key. Another key appears only as a key ID on the events made with it.
  • The API key can’t be disabled. Close has no API to disable an API key. To stop a key, delete it in Close, or deactivate its user.
  • Webhooks need Manage Groups, Users, Billing & Roles/Permissions. Without it, Oleria discovers only the webhook subscriptions the key’s user created.
  • Plan limits. Groups and custom roles need the Close Scale plan or above. On other plans, Oleria discovers no groups, and group actions fail.
  • No group owners or nesting. Close groups have no owners, can’t contain other groups, and don’t hold roles. Roles can’t be nested.

​
Contact us

For questions about this integration, contact us at support@oleria.com.