> ## 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. # LogicMonitor > Connect a LogicMonitor portal to Oleria to discover users, user groups, roles, the resource, website, dashboard, report, and collector groups those roles reach, reports and the external email addresses they go to, API-only users, API tokens, collectors, and stored credentials, plus audit log activity. LogicMonitor is an infrastructure monitoring platform. Connect your LogicMonitor portal to Oleria to see who can sign in to it and how, which roles they hold, and what those roles reach across your resource, website, dashboard, report, and collector groups. You also see which reports are emailed to people outside LogicMonitor, and the API-only users, API tokens, and collectors that act on the portal without a person at the keyboard. Oleria reads this data from the LogicMonitor REST API with an API token of a dedicated API-only user, and can take remediation actions with the same token. One Oleria integration covers one LogicMonitor portal, such as `acme.logicmonitor.com`. To connect another portal, add another integration. See [Multi-instance support](/integrations/overview.md#multi-instance-support). ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your LogicMonitor portal. ### Users, user groups, and roles * **Accounts** - every LogicMonitor user, with name, username, email, and status. Suspended users show as disabled. A user with no first or last name is shown by username. * **Last activity** - the most recent of the user's last action, last sign-in, and last access, and the last use of any API token the user owns. * **Administrators** - users who hold the built-in **administrator** role, or a role with Manage on all Settings or on User Access, are marked as administrators. Manage on only a user's own personal information or API tokens doesn't count. * **MFA** - checked in this order: API-only users show MFA as not applicable. A user with two-factor authentication turned on shows MFA as required. Otherwise, a user shows as needing to enroll when the portal, or one of the user's roles, requires two-factor authentication. Otherwise, users created through SAML sign-in show MFA as unavailable, because your identity provider enforces it, and all other users show MFA as not required. * **SSO and sign-in methods** - users created through SAML sign-in show SSO as configured and sign in with SSO. Other users sign in with a password, and their SSO status shows as unavailable (see [Known limitations](#known-limitations)). API-only users have no password, and their SSO status shows as not applicable. Users who own an enabled API token also show token sign-in and API access. * **Account role** - each user's highest-ranked role is shown as their account role, and their other roles as secondary account roles. From highest to lowest: **administrator**, custom roles with administrator access, **manager**, other custom roles (those with more Manage permissions first), **ackonly**, and **readonly**. * **LogicMonitor Support** - the `lmsupport` user that LogicMonitor creates for its Support team is shown as an external user. * **Creator and profile details** - when LogicMonitor names another user as the creator, that user is linked as the creator. Oleria also keeps the creator as LogicMonitor records it (a user, `SAML`, or `LogicMonitor`), the user type, whether a password change is forced, the IP address of the last sign-in, phone, notes, and the user's view permissions. * **User groups** - every user group, with its name, description, and members. **Ungrouped** is shown as a built-in group, and users who belong to no other group are its members. LogicMonitor user groups don't grant roles. * **Roles** - every role, with its description and the users who hold it. The four built-in roles, **administrator**, **manager**, **ackonly**, and **readonly**, are shown as standard roles, and all others as custom roles. If a user holds a role that the role listing doesn't return, for example because it was deleted or is outside the API-only user's Role Access scope, the role still appears, with a description that says its permissions are unknown. Such a role isn't used as an account role. * **Portal** - the portal itself, with whether two-factor authentication is required for the whole portal. ### Resource groups and access * **Resources** - the portal and its groups: resource (device) groups, website groups, and dashboard groups, with their folder hierarchy, plus report groups and collector groups. Each group appears inside its parent group, or inside the portal. Resource groups also show their group type, whether they're dynamic (filled by an AppliesTo query), and how many resources they contain. * **Reports** - each report, inside its report group, or directly under the portal when it's in the root report group, with read access for the people it's delivered to: LogicMonitor users who receive it, and any email address outside LogicMonitor. Each outside address appears once as an external account, with access to every report sent to it. When a report is sent to a recipient group, the LogicMonitor users and outside email addresses in that group, and in any group nested inside it, get the same read access, marked as coming from the recipient group. A LogicMonitor user in a group counts as a recipient whatever alert method the group uses for them. Outside contacts that the group reaches only by SMS, voice, or an integration don't receive reports, so they're left out. * **Role access** - what each role grants on each group, taken from the role's permissions: * **View** shows as read access, and **Manage** as full access (read, create, update, and delete). Acknowledge, SDT, and threshold permissions show as update access. **Remote Session** on a resource group shows as privileged execute access, because it opens a session on the group's resources through a collector. * A permission on a group also applies to its subgroups, unless the role sets a permission of the same kind on the subgroup itself. * A permission on all groups of a kind shows as access to every current group of that kind, and to that kind of group as a whole, so it also covers groups created later. * Collector permissions under Settings show as access to the collector groups they name, or to every collector group. * Permissions that don't target a group, such as other Settings, logs, help, private dashboards, dashboards outside any group, and LogicMonitor support access, show as access to the portal. Manage on all Settings or on User Access, and LogicMonitor support access, are marked as privileged. ### Non-human identities and credentials | Identity | Shown as | Details | | :- | :- | :- | | API-only users | API-only user | Users with API-only access, with their roles, status, and API tokens like any other user. When LogicMonitor names the user who created an API-only user, that user is shown as its owner. | | LMv1 API tokens | HMAC key | Every user's LMv1 tokens, named after the token's note, or after the owner and Access ID. Each shows its status, creation date, creator, last use, and the IP address it was last used from. | | Bearer API tokens | API token | Every user's Bearer tokens, named after the token's note, or after the owner and token ID, with the same details. | | Collectors | Workload identity | Every collector, named after its description or host name, inside its collector group. Each shows its host name, platform, build, collector type, status, whether it's down, and whether it runs with an administrator account. Unregistered and suspended collectors show as disabled. A registered collector that's up shows as active at sync time; otherwise its last activity is when it was last updated. | | Stored credentials | Secret | Custom properties on resource (device) groups and collector groups that hold a credential, shown as ` · ` inside their group. | Each API token also appears as a credential, an access key for LMv1 tokens and an API token for Bearer tokens, with its status and last use. Every token is linked to the user it belongs to: the token authenticates as that user, the user is shown as its owner, and the token can act as the user. A LogicMonitor token carries all of its owner's roles, so its credential is shown with full authority. LogicMonitor tokens don't expire, so no expiry date is shown. A token whose owner Oleria can't list appears without an owner. A custom property counts as a stored credential when it has a value and its name: * ends in `.pass`, `.password`, `.auth`, `.key`, `.accesskey`, `.secret`, or `.token`; * is `snmp.community`, `snmp.privToken`, `snmp.authToken`, `snmptrap.community`, `snmptrap.privToken`, or `snmptrap.authToken`; or * contains `password`, `credential`, or `secret`. `snmp.auth`, `snmp.priv`, `snmptrap.auth`, and `snmptrap.priv` aren't counted: they name the SNMPv3 authentication or privacy protocol, such as SHA or AES, not a secret. Each one appears as a credential held by LogicMonitor: a password when its name ends in `.pass` or contains `password`, and a stored secret otherwise. Oleria keeps the property name only. It never reads, stores, or logs the value. ### Activity Oleria imports events from the LogicMonitor audit log, including: * sign-ins, failed sign-ins, sign-outs, and users signed out by an administrator; * API requests that LogicMonitor denied; * users created, changed, suspended, reactivated, or deleted, and changes to their roles and user groups; * password changes and resets, and two-factor authentication changes; * roles and user groups created, changed, or deleted; * API tokens created, disabled, enabled, or deleted; * SSO and security setting changes; * remote sessions started, failed, or ended; * changes to credential properties; * collectors added or deleted, and other additions, changes, and deletions. Each event shows who made it, when, and from which IP address. Events Oleria doesn't recognize are kept as custom events. When an event's text names a user ID or an API token that Oleria discovered, the event is linked to that user or token. A denied API request made with a known API token is attributed to the token, acting as its owner. Events by a username Oleria can't find, such as a deleted user, are attributed to a disabled account with that username. If LogicMonitor refuses Oleria's user lookups, events by users Oleria hasn't already matched keep the username but aren't linked to an account, because Oleria can't tell whether the user still exists. Events with no user, or by `system`, are attributed to a **LogicMonitor system** machine account. For changes to credential properties, Oleria keeps only the property names, not the event's text. Changes Oleria makes appear as activity by the API-only user the integration connects as. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > Oleria doesn't import individual resources (devices), websites, dashboards, alerts, or LogicModules. LogicMonitor grants permissions on groups, so Oleria shows access at the group level. Reports are the exception, because each report has its own recipients. ## Prerequisites * A LogicMonitor portal at `.logicmonitor.com`. GovCloud portals (`.lmgov.us`) aren't supported. * A LogicMonitor user who can create roles, users, and API tokens, such as a user with the **administrator** role. * Admin access to the Oleria workspace. > [!WARNING] > > LogicMonitor rejects the API tokens of users who hold the built-in **administrator** role. Use a dedicated API-only user on a custom role, as described below. The integration depends on this user and its token: if the user is suspended or deleted, loses its role, or the token is disabled or deleted, syncs and actions stop working. ### Permissions Grant each permission with scope **All**: all user groups for User Access, all role groups for Role Access, and all groups for Resources, Websites, Dashboards, and Reports. LogicMonitor returns only what a permission's scope covers, so a narrower scope leaves data out without an error. Read permissions, for discovery: | Permission | Used for | | :- | :- | | Settings > User Access: View | Required. Users, API-only users, API tokens, and user groups. Oleria also uses it to find its own token before an action. | | Settings > Role Access: View | Required. Roles and their permissions. LogicMonitor also requires it to list users. | | Resources: View | Resource (device) groups, and the credential properties stored on them. | | Websites: View | Website groups. | | Dashboards: View | Dashboard groups. | | Reports: View | Report groups, and the reports in them with their recipients. LogicMonitor also requires Users > Permissions > Reports: View for these listings. | | Users > Permissions > Reports: View | Report groups and reports, together with Reports: View. | | Settings > Alert settings > Recipient Groups: View | The members of the recipient groups that reports are sent to. Without it, a recipient group shows only as a name on the report. The two report actions also use it. | | Settings > Collectors: View | Collectors and collector groups, and the credential properties stored on collector groups. | | Settings > Alert settings > Audit Logs: View | Activity. | If an optional permission is missing, Oleria skips that data and syncs the rest. Oleria lists LMv1 and Bearer API tokens separately. If LogicMonitor refuses one of those listings, or doesn't offer it on your portal, that kind of token doesn't appear and doesn't count toward its owner's API access, and the other kind still syncs. Other errors, such as an expired token or a LogicMonitor outage, fail the sync so that tokens don't silently go missing. Manage permissions, only for [remediation actions](#remediation-actions): | Permission | Used for | | :- | :- | | Settings > User Access: Manage | Every user, role, user group, resource access, and API token action. | | Settings > Role Access: Manage | The same actions, except disabling API tokens. | | Reports: Manage | Removing external email recipients from reports. | LogicMonitor treats Manage on User Access and on Role Access as high-risk. Add these Manage permissions only if you want Oleria to take remediation actions. ## Set up access in LogicMonitor **1. Create a custom role** In LogicMonitor, go to **Settings** > **Users and Roles** > **Roles**, and add a role for Oleria. **2. Grant the permissions** Give the role the read permissions in [Permissions](#permissions), each with scope **All**. Add the Manage permissions only if you want Oleria to take remediation actions. Save the role. **3. Create an API-only user** Go to **Settings** > **Users and Roles** > **Users**, and add an API-only user for Oleria. Assign it only the role you created. An API-only user has no password and can't sign in to the portal. **4. Add an API token** Open the API-only user and add an API token: an **LMv1** token (recommended) or a **Bearer** token. Copy the token's **Access ID** and **Access Key**, or the Bearer token, and store them securely. You enter them in Oleria next. > [!NOTE] > > To add API tokens, your own LogicMonitor role must allow creating them. The LogicMonitor interface changes over time. If these steps don't match what you see, refer to LogicMonitor's [Adding an API token](https://www.logicmonitor.com/support/adding-an-api-token) documentation. ### Choose LMv1 or Bearer Both token types act with the API-only user's role. We recommend an LMv1 token: * **LMv1** - Oleria signs every request with the Access Key, so the key itself is never sent. Before an action, Oleria finds its own token by its Access ID. * **Bearer** - Oleria sends the token with every request. Before an action, Oleria finds its own token by matching the start of the token that LogicMonitor shows in its token list. If LogicMonitor shows too little of it, actions fail (see [Remediation actions](#remediation-actions)), while discovery keeps working. ## Connect LogicMonitor to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** > **LogicMonitor**. **2. Complete the connection form** | Field | Notes | | :- | :- | | Portal | Required. Your portal name, the part before `.logicmonitor.com`, such as `acme`, or its https URL, such as `https://acme.logicmonitor.com`. Oleria keeps only the host, which must be `.logicmonitor.com`, over https on port 443. You can't change this after you connect. | | Authentication Method | Required. **LMv1 API token (Access ID + Access Key)**, the default, or **Bearer API token**. | | Access ID | Required for LMv1. The Access ID of the API-only user's LMv1 token. It has at least 8 characters, with no spaces or colons. | | Access Key | Required for LMv1. The Access Key of the same token. | | Bearer token | Required for Bearer. The API-only user's Bearer token. | **3. Authenticate** Select **Authenticate**. Before it saves anything, Oleria reads one user and one role with the token, to confirm that the token works and has Settings > User Access: View and Settings > Role Access: View. It also tries to read API tokens, resource groups, collectors, reports, recipient groups, and the audit log. A missing optional permission doesn't block the connection. Oleria then stores the Access Key or Bearer token securely. The integration is named after your portal, for example `LogicMonitor (acme)`. If the connection fails, the message says what's wrong: * **Enter your LogicMonitor portal name (the part before .logicmonitor.com) or its https URL** - check the portal. Only `.logicmonitor.com` addresses over https are accepted. * **LogicMonitor GovCloud portals (.lmgov.us) are not supported yet** - GovCloud portals can't be connected. * **Access ID is not a LogicMonitor API token Access ID** - check that you entered the token's Access ID, not its Access Key. * **LogicMonitor rejected the credential (HTTP 401)** - check the Access ID and Access Key, or the Bearer token, that the token is enabled, and that the API-only user doesn't hold the built-in **administrator** role. * **LogicMonitor denied the read (HTTP 403)** - give the API-only user's role Settings > User Access: View and Settings > Role Access: View, with scope **All**. * **LogicMonitor REST API not found (HTTP 404)** or **LogicMonitor portal ... is not reachable** - check the portal name for typos. ### Edit the connection When you edit the integration, you can replace the token or switch the authentication method. You can't change **Portal**. To connect a different portal, add a new integration. * Leave **Access Key** or **Bearer token** blank to keep the stored one. * If you change **Access ID**, enter that token's **Access Key** too, because each Access Key signs only for its own Access ID. Oleria refuses the change without it. * If you switch **Authentication Method**, enter the new method's credential. Oleria drops the old method's credential. Select **Update** to save. Oleria runs the same checks as **Authenticate**. ## Verify the integration Confirm the LogicMonitor portal appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, user groups, roles, resource groups, API tokens, and collectors appear in your Oleria workspace, and that administrators are marked as administrators. In the integration's **Capabilities and operation readiness** section, **Read users**, **Read groups**, and **Read roles** show **Available**. Each row lists `Settings -> User Access: View` and `Settings -> Role Access: View`. If one shows **Needs permission**, check that the API-only user's role still has both permissions, with scope **All**. ## Remediation actions Oleria can take these actions in LogicMonitor. Every action runs with the integration's API token, so the API-only user's role needs the Manage permissions in [Permissions](#permissions). Before it offers an action, Oleria finds its own token and checks that one of the API-only user's roles grants Manage on User Access or on all Settings, or, for the report actions, Manage on Reports. LogicMonitor checks Role Access: Manage when the change is made. If LogicMonitor refuses a change for lack of permission, Oleria reports the missing permission and nothing changes. | Action | What it does | Revert | LogicMonitor permissions | | :- | :- | :- | :- | | Disable user accounts | Suspends the user. | Supported - reactivates the user. | `Settings -> User Access: Manage`, `Settings -> Role Access: Manage`, `Settings -> User Access: View`, `Settings -> Role Access: View` | | Enable user accounts | Reactivates a suspended user. | Supported - suspends the user again. | Same as above | | Add user to role | Adds a role to the user's roles. | Supported - removes the role, unless it's now the user's only role. | Same as above | | Remove user from role | Removes a role from the user's roles. | Supported - adds the role back. | Same as above | | Add user to group | Adds the user to a user group. | Supported - removes the user from the group. | Same as above | | Remove user from group | Removes the user from a user group. | Supported - adds the user back to the group. | Same as above | | Delete user | Deletes the user from the portal. The action's result records the username. | Not supported. A deleted user can't be restored. | Same as above | | Create user | Creates a LogicMonitor user with the built-in **readonly** role, in the user groups you choose. LogicMonitor requires a password: give one, or choose to generate one. Without either, the action fails and nothing changes. Oleria sets the user to change it at first sign-in. Oleria never shows or stores the password. | Supported - deletes the user, while it's still the user the action created. | Same as above | | Revoke permission to a resource | Removes one user's access to one resource (device) group, website group, dashboard group, report group, or collector group, by removing the user from the roles that grant it. Oleria never edits the role itself, because that would change access for everyone who holds it. Individual reports and the portal itself aren't valid targets: for a report, target its report group, or use **Revoke external access to a report**. | Supported - adds the removed roles back. | Same as above, plus View on that kind of group, such as Resources: View for a resource group. The read permissions in [Permissions](#permissions) include it. | | Revoke external access to a report | Removes every email address outside LogicMonitor from a report's recipients. LogicMonitor users who receive the report keep it. A recipient group that sends the report to an outside address is replaced on the report by the group's LogicMonitor users. | Supported - adds the removed addresses and recipient groups back, and removes the users the action added. | `Reports: Manage`, `Reports: View`, `Users -> Permissions -> Reports: View`, `Settings -> Alert Settings -> Recipient Groups: View`, `Settings -> User Access: View`, `Settings -> Role Access: View` | | Remove access for an external account | Removes one outside email address from the recipients of one report, or of every report that is sent to it, directly or through a recipient group. A recipient group that sends the report to the address is replaced on the report by the group's other members. | Supported - adds the address and recipient groups back to those reports, and removes the recipients the action added. | Same as the row above | | Disable NHI | Disables an LMv1 or Bearer API token, or suspends an API-only user. | Supported - re-enables the token, or reactivates the API-only user. | Tokens: `Settings -> User Access: Manage`, `Settings -> User Access: View`, `Settings -> Role Access: View`. API-only users: the four permissions above. | | Identity | Disable NHI supported | | :- | :- | | LMv1 API token | Yes - disables the token. | | Bearer API token | Yes - disables the token. | | API-only user | Yes - suspends the user. | | Collector | No. LogicMonitor has no way to suspend a collector, and deleting one stops monitoring every resource it serves. | | Stored credential | No. It's a custom property on a group: deleting it breaks monitoring, and Oleria can't rotate its value. | | LogicMonitor system account | No. It's the platform itself, not an identity that can be disabled. | > [!WARNING] > > **Delete user** can't be undone. The user's ID, password, API tokens, and two-factor enrollment are gone, and anything that uses the user's tokens stops working. To remove a user's access but keep the user, use **Disable user accounts** instead. Keep these in mind when you use these actions: * **Oleria never acts on its own connection.** It refuses to suspend or delete the API-only user the integration connects as, to change that user's roles, user groups, or resource access, and to disable the API token the integration uses. Reverting **Enable user accounts** follows the same rule. * **Use an LMv1 token if you plan to run actions.** To apply that rule, Oleria must find its own token in LogicMonitor's token list. If it can't find exactly one match, every action fails with **cannot verify the connection's own identity — use an LMv1 token**, and nothing changes. This can happen with a Bearer token. * **Every user keeps at least one role.** **Remove user from role** refuses to remove a user's last role, and **Revoke permission to a resource** refuses when it would leave the user with no role. To end a user's access, use **Disable user accounts**. * **Ungrouped isn't a target.** **Add user to group** and **Remove user from group** refuse **Ungrouped**, because a user with no other group is in it automatically. * **`lmsupport` is LogicMonitor Support's access.** **Disable user accounts** works on it, but the action's result warns that suspending it may limit LogicMonitor Support's ability to troubleshoot. **Delete user** refuses it: suspend it instead. * **Replacing a recipient group can start email delivery.** When a report action replaces a recipient group with its members, LogicMonitor users the group reaches by SMS or voice are added as recipients too, and may start getting the report by email. The action's result lists every recipient it added, and reverting the action removes them. > **How user, group, role, and token actions apply changes** > > * Oleria reads the user or token before it changes anything. If it's already in the requested state, the action succeeds without a change, and reverting it makes no change either. After a change, Oleria confirms it from LogicMonitor's response or by reading the user or token again. If the change doesn't show, the action fails. > * If the user is already deleted, **Delete user** succeeds without a change, and its result says the user was already deleted. > * Reverting an action undoes only the change it made, and only while the user or token is still in the state the action left it in. If someone changed it in between, Oleria leaves it as it is and says so. If the user or token no longer exists, the revert makes no change. > * **Add user to role** and **Remove user from role** replace the user's role list, and **Add user to group** and **Remove user from group** replace the user's group list, with the list Oleria read plus or minus the one change. A change someone makes in LogicMonitor between that read and the write can be overwritten. > * **Add user to role** refuses to give an API-only user the built-in **administrator** role, because LogicMonitor rejects the API tokens of users who hold it. It also fails if the role doesn't exist. > * When Oleria can read the user group list, **Add user to group** and **Remove user from group** refuse a group that doesn't exist. > * **Create user** makes no change if a user with that username already exists. It refuses if the portal has no built-in **readonly** role. To give the new user other roles, use **Add user to role** afterwards. > * **Disable NHI** on an API-only user refuses a user who isn't API-only. Use **Disable user accounts** for other users. > * User actions apply to LogicMonitor users only. API tokens, collectors, stored credentials, and audit log actors can't be suspended, deleted, or given roles or groups. > **How Revoke permission to a resource chooses roles** > > * Oleria removes a role only when everything the role grants stays inside the target group and its subgroups. If a role that grants the access also grants other groups or portal-wide settings, the action refuses, names the role, and changes nothing. Remove the user from that role, or edit the role in LogicMonitor. > * The action also refuses when the user holds a role that the role listing doesn't return, because Oleria can't check what that role grants. > * The portal isn't a target, because portal-wide permissions also reach other groups. To end a user's access to the whole portal, use **Disable user accounts**. > **How the report actions change recipients** > > * **Revoke external access to a report** and **Remove access for an external account** replace the report's recipient list with the list Oleria read minus the outside addresses, then read the report again to confirm. If the change fails or doesn't show, Oleria puts the recipients back before it reports the error. If a report has no outside recipients, the action succeeds without a change. > * These two actions change only reports, so they don't need User Access: Manage or Role Access: Manage. Like every action, they need User Access: View and Role Access: View to find Oleria's own token and check its roles. > * Oleria never edits a recipient group, because escalation chains use the same groups to decide who gets paged. Instead, on the report only, it replaces a group that sends the report to an outside address with the group's remaining members as individual recipients, skipping anyone who already receives the report. Groups without outside members stay as they are, and so does a group inside a replaced group that doesn't send the report to an address being removed. The report no longer follows later changes to a replaced group; reverting the action puts the group back. > * When Oleria replaces a group with its members, it leaves out members that aren't current LogicMonitor users, and the action's result names them. > * If Recipient Groups: View is missing, Oleria doesn't guess what the groups contain. When a report it would change is sent to a recipient group, the action fails before it changes anything and names the groups and the missing permission, even if the report also lists outside addresses directly, so a report is never left half cleaned. When **Remove access for an external account** runs on every report sent to the address, this check covers all reports in the portal: if any report is sent to a recipient group, the action refuses before it changes anything. > * If two recipient groups have names that differ only in upper and lower case, Oleria can't tell which one a report means, so the action refuses before it changes anything. Rename the groups so their names differ by more than case. > * If removing the outside addresses would leave a report with no recipients, Oleria also turns off the report's email delivery in the same change, and reverting the action turns it back on. ## Known limitations * **GovCloud portals aren't supported.** Oleria connects only to `.logicmonitor.com` portals over https. Portals on `.lmgov.us` are refused when you connect. * **Sessions can't be revoked.** LogicMonitor doesn't document an API to sign users out, so Oleria doesn't offer **Revoke user sessions**. Use **Disable user accounts** to suspend the user instead. * **Activity is classified from free text.** LogicMonitor's audit log records each event as a sentence, with no event type, target ID, or session ID. Oleria classifies events by matching their text. Only sign-ins and denied API requests match wording that LogicMonitor documents. Other matched events carry the label `unverified pattern`, and events Oleria doesn't recognize are kept as custom events. An event is linked to the user or token it affects only when its text names a user ID or an API token. * **Activity covers up to 90 days.** Oleria reads the audit log back to 90 days before the sync, and then keeps it up to date. Within a single minute with more than 10,000 audit log entries, Oleria reads the first 10,000. * **User groups come from an undocumented endpoint.** LogicMonitor's REST API v3 doesn't document a user group listing, so Oleria reads user groups the way LogicMonitor's own PowerShell module does. If LogicMonitor refuses that listing or doesn't offer it on your portal, Oleria still shows each group that users belong to, named **User group** followed by its ID, and the rest of the sync continues. Group membership comes from each user's record either way. Other errors, such as an expired token or a LogicMonitor outage, fail the sync so that groups don't silently go missing. * **No user creation date or last password change.** LogicMonitor doesn't record either for users. * **SSO shows only for SAML-provisioned users.** SSO configuration, including **Restrict Single Sign On**, isn't available through the API. Users created through SAML sign-in show SSO. A local user who later signs in with SSO doesn't. * **No MFA factor.** Oleria sees whether a user has two-factor authentication turned on, not which factor they use. Two-factor policy beyond the user and role settings isn't available through the API. * **Portal security settings aren't read.** Inactivity suspension, the API token auto-disable period, IP and email-domain allowlists, and SCIM configuration and tokens are set in the LogicMonitor interface only. * **API tokens have no expiry or scope.** LogicMonitor tokens don't expire and always carry all of their owner's roles. * **Groups only, not individual objects.** LogicMonitor grants permissions on groups, so Oleria doesn't inventory individual resources, websites, or dashboards. Reports are inventoried with their recipients, including the members of the recipient groups they're sent to. Credential properties set on single resources or on cloud groups aren't covered. Role groups and access groups aren't shown. * **Next-gen reports may be missing.** Oleria reads reports from LogicMonitor's report listing without asking it to include next-gen reports. If that listing leaves out your portal's next-gen reports, they and their recipients aren't shown, and **Remove access for an external account** doesn't remove the address from them. Check those reports in LogicMonitor. * **Reports in the root report group appear under the portal.** A report that isn't in a report group is shown directly under the portal. * **Recipient groups appear as members, not as groups.** A recipient group isn't shown as an object: its members get access to the reports sent to it. LogicMonitor users in a group count whatever alert method the group uses for them, so a user the group reaches only by SMS or voice can show access to a report. Outside contacts reached only by SMS, voice, or an integration aren't shown. Without Settings > Alert settings > Recipient Groups: View, a group is only a name on the report, and its members aren't shown. * **Combined grants show the higher level.** When a role grants a permission on all groups of a kind and a different permission on one of those groups, Oleria shows the higher of the two on that group. * **No nested groups or group roles.** LogicMonitor user groups don't contain other groups or grant roles, and roles don't contain other roles. A user's access is the sum of their own roles. * **Collectors can't be disabled.** LogicMonitor has no suspend state for a collector. Oleria never reads a collector's own credentials. * **No AI agents.** LogicMonitor's API has no AI agents. Collectors are monitoring agents and appear as workload identities. * **Partner and embedded access isn't visible.** Access to the portal from a partner or parent portal can't be seen from the portal's API. Embedded dashboard widget tokens aren't listed. * **No license level.** LogicMonitor licenses monitored resources, not users. ## 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.