> ## 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.

# Epic

> Connect Epic to Oleria to bring your Epic users, the security templates, sub-templates, and user roles linked to them, their user groups, and the external-system logins stored on them into your identity and access graph.

Connect Epic to Oleria to see who can sign in to your Epic environment, which security templates they can use, which user groups they're in, and which external-system logins Epic stores for them. Oleria reads Epic user records through your Epic Interconnect web services as a dedicated Epic service user, so you can review access in Oleria and inactivate users directly from it.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Epic environment:

* **Accounts** - every Epic user (EMP) record, active and inactive, with the user's name and directory login. A user shows as enabled only when it's active in Epic and not blocked. Oleria also shows the user's end date (and flags users whose end date has passed), when the record was last changed, and whether the user signs in through an external authentication configuration such as Active Directory. Template and sub-template records that are linked to at least one user aren't shown as users.
* **Roles** - the linkable templates, sub-templates, and user roles linked to your users, with each user's assignments. A user's first linked template is shown as their primary role. Templates appear by name when Epic returns one, and by ID otherwise.
* **User groups** - the Epic user groups your users are in, with each user's memberships. User groups route In Basket messages and reports and don't grant access, so Oleria shows them without permissions.
* **Credentials** - the logins for external systems that Epic stores with a password on a user's record (external identifiers), each shown as a password credential held by Epic and linked to its user, with whether it's active. Identifiers without a password are mappings to other systems and aren't shown as credentials. Oleria keeps only the identifier, its system, and its status. If Epic includes a stored password in its response, Oleria discards it without reading, logging, or storing it.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model).

> [!NOTE]
>
> Oleria doesn't read patient data. This integration covers identity and access governance for Epic users and their security templates only.

## Prerequisites

* Epic Interconnect web services for your Epic environment, reachable from the internet at a public HTTPS address, for example through a reverse proxy. Oleria doesn't connect to private network addresses and doesn't follow redirects.
* The Epic client ID issued for Oleria, enabled by your Epic team for **Core GetRecords**, **Personnel Management ViewUser**, and **Personnel Management ViewUserGroups**. Ask your Oleria contact for the client ID.
* Optional: to use the [remediation actions](#remediation-actions), also enable **InactivateUser** and **ActivateUser** for the client ID. Oleria connects and syncs without them, and you can enable them later.
* An Interconnect security policy that accepts username tokens (Basic authentication) over TLS for those services.
* A dedicated Epic service user for Oleria.
* Oleria's IP addresses allowed by your firewall or reverse proxy. Contact [support@oleria.com](mailto:support@oleria.com) for the current list.
* Admin access to the Oleria workspace.

> [!WARNING]
>
> Create a dedicated Epic service user for Oleria instead of using a named person's account. The connection stops working if that person leaves, is inactivated, or changes their password.

## Set up Epic for Oleria

**1. Enable the web services for Oleria's client ID**

Ask your Epic team to enable Oleria's client ID for **Core GetRecords**, **Personnel Management ViewUser**, and **Personnel Management ViewUserGroups** on your Interconnect server, with a username-token (Basic) security policy over TLS. To use the [remediation actions](#remediation-actions), also enable **InactivateUser** and **ActivateUser**. You can enable them later.

**2. Create the service user**

Create an Epic user (EMP) record for Oleria, for example `OLERIASVC`. Make it an active foreground user, and set its password not to expire.

**3. Publish Interconnect**

Make your Interconnect instance reachable at a public HTTPS address, including its instance path, for example `https://interconnect.example-health.org/Interconnect-PRD-WEB`. Allow Oleria's IP addresses.

> [!NOTE]
>
> The exact steps depend on how your Epic environment is hosted and configured. If they don't match what you see, work with your Epic team or refer to Epic's own documentation.

## Connect Epic to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations** -> select **Epic**.

**2. Complete the connection form**

Select **Continue** and provide the following:

| Field | Notes |
| :- | :- |
| Interconnect URL | Required. The public HTTPS address of your Interconnect instance, including the instance path, for example `https://interconnect.example-health.org/Interconnect-PRD-WEB`. You can't change this after you connect. |
| Epic client ID | Required. The client ID your Epic team enabled for Oleria. |
| EMP user ID | Required. The EMP ID of the Epic service user you created. The `emp$` prefix is optional. |
| Password | Required. The password of that service user. Oleria stores it encrypted after it validates the credentials. |

**3. Confirm the connection**

Select **Authenticate**. Oleria reads the service user's own record and the first page of your Epic user list before it saves anything. If either fails, Oleria shows what's missing, for example a web service that isn't enabled for the client ID. Find the newly connected environment on the **Connected** tab of your Oleria **Integrations** page.

> [!NOTE]
>
> **Authenticate** checks that Oleria can read users and their user groups, so it fails if **ViewUserGroups** isn't enabled for the client ID. It can't check whether **InactivateUser** and **ActivateUser** are enabled. If they aren't, the connection saves and syncs normally, and the remediation actions show as available but fail when you run them.

## Verify the integration

Confirm the Epic environment appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that your Epic users and their templates appear in your Oleria workspace.

> [!WARNING]
>
> If you change the service user's password in Epic, update it in Oleria right away: edit the integration, enter the new password, and select **Update**. Until you do, syncs and actions fail. Oleria stops a sync at the first rejected password instead of retrying for every user, which limits failed sign-in attempts but doesn't prevent them. If your Epic environment locks users after failed sign-ins, the service user can be locked out.

> [!NOTE]
>
> When you edit the integration, you can change the client ID, the EMP user ID, and the password. If you change the EMP user ID, you must also enter that user's password. To connect a different Epic environment, add a new integration.

## Remediation actions

Oleria can take these actions in Epic. Each one runs as the connection's service user:

* **Inactivate a user**. Requires the **InactivateUser** web service. Undoing it reactivates the user.
* **Reactivate a user**. Requires the **ActivateUser** web service. Undoing it inactivates the user again.

Keep these limits in mind when you use these actions:

* Oleria reads the user first. If the user is already in the requested state, Oleria changes nothing, and undoing the action also changes nothing.
* Oleria won't inactivate or reactivate the connection's own service user, because that would disconnect the integration.
* Oleria won't reactivate a user who is blocked in Epic, because reactivating doesn't remove a block and the user still couldn't sign in. Remove the block in Epic first.
* If Oleria can't confirm that an inactivation took effect, it reports the action as failed. Check the user in Epic.
* If Epic reported an error but the user ended up inactive anyway, Oleria reports the inactivation as done but won't undo it, because it can't confirm it made the change. Reactivate the user in Epic if needed.
* Oleria doesn't change a user's templates, sub-templates, or user roles.

## Known limitations

* **No activity or last-login data.** Epic doesn't provide its access logs through Interconnect web services, so Oleria doesn't import activity or last sign-in dates. Oleria can't detect dormant Epic users.
* **No email addresses.** Epic doesn't return a user's email address through these web services. Oleria matches Epic users to your other identities by their directory login, when Epic has one for the user. Users without one, such as Epic-only or background users, usually aren't matched to your other identities.
* **No MFA status.** Epic two-factor settings aren't available through these web services, so MFA shows as unavailable.
* **No template permissions or administrator flag.** The security classes behind a template aren't available through these web services, so Oleria doesn't show what a template grants or mark users as administrators.
* **Only assigned templates appear as roles.** Oleria shows the templates, sub-templates, and user roles that are linked to at least one user.
* **Unused templates can appear as users.** Epic's web services don't mark which user records are templates, so Oleria recognizes a template only when a user is linked to it. A template or sub-template record nobody is linked to appears as a user account.
* **Some user records may be skipped.** If Epic can't return an individual user record, Oleria skips it for that sync, so the user may briefly appear removed until a later sync reads it. If more than 5% of records (at least 10) can't be read, the sync fails instead of dropping them. The same applies to each user's groups.
* **No non-human identities.** Epic's web services don't mark background or interface users, so every Epic user appears as a standard user.
* **Large environments take time to sync.** Oleria reads each user and the user's groups individually, at about five requests per second, so an environment with 50,000 user records takes about six hours to sync.

## 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.