What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from Boomi:- Accounts - every user with a role in the account or in one of its account groups. Each account shows its roles, whether a role grants account administration (the
ACCOUNT_ADMINprivilege, directly or through an inherited role), single sign-on status, and the last sign-in Oleria found in the past 12 months of the audit log. - Roles - Boomi’s built-in roles and your custom roles, including which built-in role a custom role inherits from, and which users hold each role.
- Account groups - each account group and the users in it, with the roles they hold in the group.
- Shared Web Server users - the users that call web services published on your runtimes, shown as non-human identities (service accounts), each with its API token or client certificate as a credential. Oleria never reads or stores the token value.
- Activity - Boomi audit log events, including sign-ins, users added or removed, role changes, account group membership changes, and API token changes.
Prerequisites
- A Boomi user, ideally dedicated to Oleria, whose role includes the
APIandACCOUNT_ADMINprivileges. The built-in Administrator role has both. - To connect with a password instead of a Platform API token, the user must be a regular (non-SSO) user or an SSO administrator, and must not use two-factor authentication. Boomi accepts a password only from those users, and Oleria can’t send the per-call code that two-factor authentication requires. Other users need a Platform API token.
- Optional: Runtime Management Read Access (
ATOM_MANAGEMENT_READ_ONLY) to discover Shared Web Server users, andVIEW_AUDIT_LOGSfor activity and last sign-in. - Admin access to the Oleria workspace
Boomi doesn’t offer service accounts or OAuth clients for its Platform API. Every token and password belongs to a Boomi user and carries that user’s roles, so use a dedicated user and give its role only the privileges above.
Create a Platform API token in Boomi
Skip the token steps if you connect with a password, but still find your account ID.1
Sign in as the integration user
Sign in to the Boomi Enterprise Platform as the Boomi user that Oleria will use.
2
Open Platform API Tokens
Select Settings -> My User Settings -> Platform API Tokens.
3
Create the token
Select Add New Token, enter a name such as
Oleria Integration, and select Generate Token.4
Copy the token
Copy the token now.
5
Find your account ID
Select Settings -> Account Information and Setup and copy the Account ID.
Connect Boomi to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations -> select Boomi.
2
Complete the connection form
Select Continue and provide the following:
3
Confirm the connection
Select Authenticate. Oleria checks the token or password against your Boomi account before saving it. Find the connected Boomi instance on the Connected tab of your Oleria Integrations page.
Verify the integration
Confirm the Boomi instance appears on the Connected tab of your Oleria Integrations page. After the first sync completes, review the discovered accounts, roles, and account groups in your Oleria workspace.Remediation actions
Oleria runs actions as the Boomi user the connection signs in as. Before an action runs, Oleria checks that the user’s roles grant theAPI and ACCOUNT_ADMIN privileges, directly or through an inherited role. Every action needs both.
If the user already has, or already lacks, the access an action changes, Oleria makes no change. Oleria refuses to remove access from the Boomi user the connection uses.
If Disable user accounts, Delete user or Remove user from group fails partway, the roles already removed stay removed and the action can’t be reverted. Check the user’s roles in Boomi and add them back there.
Known limitations
- Platform API tokens aren’t discovered. Boomi’s API doesn’t list user API tokens. Token creation, renaming, disabling, and revocation still appear as audit activity.
- Runtime installer tokens and API Management API keys aren’t discovered. Boomi’s Platform API can’t list them. Their changes still appear as audit activity.
- No disabled or locked state. Boomi users either have access or are removed. A user Boomi locked out after failed sign-ins still shows as enabled, because the API doesn’t report locks.
- No MFA, creation, or password change dates. Boomi’s API doesn’t expose two-factor settings or these dates, so Oleria shows them as unavailable.
- No failed sign-ins or IP addresses. Boomi’s audit log doesn’t record failed sign-ins and has no IP address or device for any event. Boomi keeps audit entries for 12 months.
- Environments, runtimes, folders, and processes aren’t discovered. This is an identity governance integration.
- Account groups’ member accounts aren’t discovered. Only the users in each account group are.
- Shared Web Server users can’t be disabled from Oleria. Boomi has no disable setting for them.
- Adding a user to an account group isn’t supported, because Boomi requires a role for each group membership.

