> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # Bynder > Connect Bynder to Oleria to bring users, security profiles, groups, brands, collections, public assets, access rights, non-human identities, and activity from your digital asset management portal into your identity and access graph. Connect Bynder to Oleria to see who has access to your Bynder portal and to the content in it: its users and their security profiles, its groups, and who can see or edit access-controlled assets. Oleria reads this data through a Bynder OAuth app that acts as a Bynder user you choose, so you can see where access is over-provisioned and take action directly from Oleria. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Bynder portal: * **Accounts** - every user in your portal, active and deactivated, with their name, email address, alternate email address, username, job title, department, and last login. For deactivated users, Oleria reads only the fields in Bynder's user list, so their job title, department, and last login are empty. Users marked as **SSO user** in Bynder are shown as requiring single sign-on. Users whose security profile requires multi-factor authentication on login are shown as requiring MFA - see [Known limitations](#known-limitations). Users whose security profile can manage users, groups, or permissions are marked as administrators. * **Roles** - every security profile, as a role and an account role, with the profile each user holds. Oleria also maps what each profile allows on assets, collections, and access-controlled options, such as editing, deleting, or making assets public. * **User groups** - portal user groups with their members, and, if your portal has Bynder Workflow, Workflow user groups with their members and the user who created them. * **Resources** - brands and sub-brands, collections (with their owner and whether they have a public link), public assets, Brand Guidelines guides if your portal has Brand Guidelines (with their owner and visibility), and metaproperty options that have access rights. * **Access rights** - for each access-controlled metaproperty option, which users, groups, and security profiles are granted access to its assets, and who is explicitly hidden from them. Public collections, public assets, and public guides are shown as accessible to anyone with the link. * **Non-human identities** - the OAuth app Oleria connects with and its client secret, with the scopes it was granted and the Bynder user it acts as. * **Activity** - events from Bynder's Analytics API: sign-ins, user creations, asset views, downloads, uploads, removals, archives and deletions, and collection views. Events on assets and collections that Oleria doesn't import (see the note below) show who acted, but aren't linked to a resource. Views and downloads that Bynder records without a user, such as through public links, appear as anonymous activity. Activity requires Bynder's **Analytics for BI Access** add-on - see [Prerequisites](#prerequisites). Oleria refreshes users, groups, and resources on its [regular sync schedule](/integrations/overview.md#sync-model). Bynder makes analytics data available with a delay of up to 24 hours, so Oleria imports each event about 24 hours after it happens, and the first sync reaches back at most 12 months. > [!NOTE] > > Oleria doesn't inventory every asset in your portal. It imports public assets individually and represents access to all other assets through the access-controlled metaproperty options and security profiles that govern them. ## Prerequisites * A Bynder portal on its original Bynder domain, ending in `.bynder.com` or `.getbynder.com`. Custom domains aren't supported. * **OAuth Apps** enabled for your portal. If you don't see **Settings** > **Advanced Settings** > **Portal settings** > **OAuth Apps**, ask Bynder Customer Support to enable it. If OAuth Apps is enabled but you still don't see it, check that your security profile has the **Manage OAuth apps** permission. * A dedicated Bynder user for the OAuth app to act as. Its security profile must have the **USERMANAGEMENT**, **GROUPMANAGEMENT**, and **PERMISSIONMANAGEMENT** permissions. * Optional: Bynder's **Analytics for BI Access** add-on, to collect activity. * Admin access to the Oleria workspace. For a complete inventory and for remediation actions, also give the integration user's security profile: | Permission | Needed for | | :- | :- | | **PUBLICCOLLECTIONS**, **INBOXPUBLIC**, **OUTBOXPUBLIC** | Seeing collections other users created, shared, or received. Without them, Oleria sees only the integration user's own collections. | | **METAPROPERTYMANAGEMENT** | Reading access rights on metaproperty options, and revoking them. Without it, Oleria doesn't import access-controlled options. | | **COLLECTIONS**, **PUBLISHCOLLECTIONS** | Unpublishing collections. | | Asset Workflow **Manage user groups** | Workflow user groups, if your portal has Bynder Workflow. Without it, Oleria skips Workflow user groups. | | **Viewer** (or higher) for guides in the CX User Community permissions | Brand Guidelines guides, if your portal has Brand Guidelines. Without it, Oleria skips guides. | > [!WARNING] > > Use a dedicated Bynder user instead of a named person's account. Every call Oleria makes runs with this user's security profile. If the user is deactivated or loses these permissions, syncs and actions stop working. ## Register an OAuth app in Bynder **1. Create the app** Sign in to Bynder as a user with the **Manage portal settings** and **Manage OAuth apps** permissions. Go to **Settings** > **Advanced Settings** > **Portal settings** > **OAuth Apps** and register a new application for Oleria. **2. Choose the grant type and assigned user** Select the **Client Credentials** grant type and choose the dedicated integration user as the app's assigned user. Oleria doesn't use any other grant type. **3. Select the scopes** Select the scopes for what you want Oleria to do: | Scope | Needed for | | :- | :- | | `admin.user:read`, `admin.profile:read`, `admin.group:write` | Required. Syncing users, security profiles, and groups. Bynder has no read-only scope for groups, so reading them needs `admin.group:write`. | | `collection:read` | Optional. Collections. | | `asset:read` | Optional. Public assets. | | `meta.assetbank:read`, `meta.assetbank:write` | Optional. Access-controlled metaproperty options and their access rights. Bynder requires `meta.assetbank:write` even to read access rights, so select both. `meta.assetbank:write` also allows revoking a user's access to an option. | | `workflow.group:read` | Optional. Workflow user groups. Also needs the assigned user's Asset Workflow **Manage user groups** permission. | | `guidelines.guide:read` | Optional. Brand Guidelines guides. Also needs the assigned user's guide **Viewer** permission. | | `analytics.api:read` | Optional. Activity. Requires the **Analytics for BI Access** add-on. | | `admin.user:write` | Optional. Deactivating, reactivating, and deleting users, and changing a user's security profile. | | `collection:write` | Optional. Unpublishing collections. | You can't change an app's scopes after you create it. To add a scope later, create a new app and update the integration in Oleria. **4. Copy the credentials** Copy the app's client ID and client secret. Bynder shows the client secret only once. > [!NOTE] > > The exact location of these settings can change over time. If the steps above don't match what you see, refer to Bynder's own documentation. ## Connect Bynder to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **Bynder**. **2. Complete the connection form** Select **Continue** and provide the following: | Field | Notes | | :- | :- | | Portal domain | Required. Your portal's Bynder domain, such as `yourcompany.bynder.com` or `yourcompany.getbynder.com`. You can't change this after you connect. | | Client ID | Required. The client ID of the OAuth app you registered. | | Client secret | Required. The client secret of the same app. Oleria stores it encrypted after it validates the credentials. | **3. Confirm the connection** Select **Authenticate**. Before it saves anything, Oleria requests a token, reads the app's assigned user, and checks that the user's security profile has the **USERMANAGEMENT**, **GROUPMANAGEMENT**, and **PERMISSIONMANAGEMENT** permissions and, when Bynder reports the app's scopes, that the app has the three required scopes. Find the newly connected portal on the **Connected** tab of your Oleria **Integrations** page. > [!NOTE] > > Besides valid credentials for a Bynder domain, **Authenticate** requires only the permissions and scopes marked as required. A missing optional scope or permission, or a missing **Analytics for BI Access** add-on, doesn't stop the connection: Oleria skips the data it can't read. Confirm the data after the first sync, as described in [Verify the integration](#verify-the-integration). ## Verify the integration Confirm the Bynder portal appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, security profiles, groups, and collections appear in your Oleria workspace, and that the OAuth app appears as a non-human identity. If you have the **Analytics for BI Access** add-on, allow at least 24 hours, plus one sync, for activity to appear. > [!NOTE] > > When you edit the integration, you can change the client ID and client secret. Leave **Client secret** blank to keep the stored secret, and enter it again if you change the client ID. To connect a different portal, add a new integration. ## Remediation actions Oleria can take these actions in Bynder. Each one runs with the security profile of the OAuth app's assigned user and needs the scopes and permissions listed: | Action | Scopes | Assigned user's permissions | | :- | :- | :- | | **Deactivate a user**, **reactivate a user**, **delete a user** | `admin.user:read`, `admin.user:write` | **USERMANAGEMENT** | | **Change a user's security profile** | `admin.user:read`, `admin.user:write`, `admin.profile:read` | **USERMANAGEMENT** | | **Add a user to a group**, **remove a user from a group** | `admin.user:read`, `admin.group:write` | **GROUPMANAGEMENT**, **USERMANAGEMENT** | | **Create a group** | `admin.group:write` | **GROUPMANAGEMENT** | | **Revoke a user's access to a metaproperty option** | `meta.assetbank:read`, `meta.assetbank:write` | **METAPROPERTYMANAGEMENT** | | **Unpublish a collection** | `collection:read`, `collection:write` | **COLLECTIONS**, **PUBLISHCOLLECTIONS** | If the OAuth app or its assigned user doesn't have an action's scopes and permissions, that action isn't available for the integration. Keep these limits in mind when you use these actions: * Oleria reads the user, group, option, or collection before it changes anything. If it's already in the requested state, Oleria makes no change. * After a change, Oleria reads it back. The action succeeds only when Bynder shows the change. If Bynder accepted the change but Oleria can't see it yet, the action fails and asks you to check the user, group, option, or collection in Bynder. Oleria never sends a second write to undo it. * Reverting an action undoes only the change that action made. If someone changed the same user's security profile after the action, Oleria doesn't overwrite it. * **Change a user's security profile** replaces the user's profile, because a Bynder user holds exactly one profile. Reverting restores the previous profile. * **Reactivate a user** may be refused by Bynder, which allows reactivating a user only 180 days after deactivation. Ask Bynder Customer Support to reactivate a user sooner. Reverting a deactivation can hit the same limit. * **Delete a user** can't be reverted. * **Add a user to a group** and **remove a user from a group** work on portal user groups only. Oleria doesn't change Workflow user group membership. * **Create a group** is reverted by deleting the group, but only while it has no members. * **Revoke a user's access to a metaproperty option** removes only the user's own access rights on that option. It never removes a rule that hides assets from the user. If the user also gets access to the option through a group or a security profile, the action fails without changing anything and names that group or profile, because removing the user's own rights wouldn't remove the access, and removing the group's or profile's rights would remove it for everyone else. Remove the user from that group or change that rule in Bynder. If an option has more access rights than Oleria can read, if an access level the user holds also carries a rule of another type, or if any other user's, group's, or profile's access rights change during the action, the action fails so you can check the option in Bynder. * **Unpublish a collection** removes its public link. Bynder doesn't allow making a public asset private again, so Oleria can't unpublish public assets, and it can't change a Brand Guidelines guide's visibility. * Oleria won't deactivate, delete, re-profile, or change the group membership or option access of the OAuth app's assigned user, because that would disconnect the integration or hide content from it. ## Known limitations * **Activity needs the Analytics for BI Access add-on.** Without it, Oleria doesn't import activity. Activity is imported about 24 hours after it happens, and Bynder keeps analytics data for 12 months. * **No last password change or account creation date.** Bynder's API doesn't report them. * **MFA from security profiles only.** Bynder enforces MFA per security profile, and its API doesn't document the name of that permission. Oleria treats a profile permission whose name contains "MFA" together with "REQUIRE" or "LOGIN" as requiring MFA, so permissions that only administer MFA, such as resetting it, don't count. If at least one profile in your portal has such a permission, password users on other profiles are shown as not requiring MFA. If none does, their MFA status is shown as unavailable. Users who sign in with SSO aren't prompted for Bynder MFA. * **Only Oleria's own OAuth app is discovered as a non-human identity.** Bynder's API doesn't list other OAuth apps, permanent tokens, or AI agents. * **Collection shares and brand restrictions aren't visible.** Bynder's API doesn't report who a collection is shared with, or which brands a user can see. * **Assets hidden from the integration user.** A public asset that a metaproperty rule hides from the integration user can't be listed, because Bynder applies hide rules to administrators too. * **Large access lists.** If a metaproperty option has more than 1,000 access rights, Oleria may import only some of them. Those options are labelled, and Oleria won't revoke access on them. * **Rate limits.** Bynder limits API calls per source IP and blocks all calls for five minutes after the limit is reached. Oleria slows its requests to stay under the limit and waits out a block before it retries. * **Original Bynder domains only.** Oleria connects only to `.bynder.com` and `.getbynder.com` domains over HTTPS. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.