Overview
The Veeva Vault integration reads which licence type each of your Vault users holds — so the seats you pay for can be compared with the seats in use.
What the connection is for
Vault distinguishes between licence types — a full user, a read-only user and an external user are not the same commitment. A sign-in record cannot tell them apart. Only Vault’s own user data can, and that is what this connection is built to read.
Key Benefits
- Licence-type accuracy — the licence each named user holds, rather than a count of people who signed in
- Reconciliation against your contract — the seats in your Veeva agreement compared with the seats assigned
- Reclaim candidates — full licences held by people whose activity does not justify one
What you get
- A self-serve connection on the Integrations page, in either of two authentication modes
- Your credentials stored encrypted against your tenant
- Connection status visible to your team
Prerequisites
You need a License Logic account and a Vault administrator. Which prerequisites apply depends on which of the two authentication modes you choose — see Setup Guide before gathering anything.
License Logic Requirements
- Account: active License Logic subscription
- Role: a role holding Settings: Edit — that is what the Connect action checks
- Page: Integrations in the left sidebar, which requires Integrations: View
If the Integrations page is missing, or Connect does nothing. These are two different permissions. Integrations: View shows the page and the tiles; Settings: Edit is what allows a connection to be made. A user can hold the first without the second, see the tile, and be unable to complete the connection. Your License Logic administrator grants both in People → Roles.
Veeva Vault Requirements — both modes
- Account: an active Veeva Vault
- Role: a Vault administrator (System Administrator or Vault Owner) to create the account and, for OAuth, the profile
- A permission set granting API access for the account the integration runs as. Without it, authentication can succeed and every subsequent call still fail
- Your Vault DNS — for example
yourcompany.veevavault.com
Additional requirements for OAuth 2.0 mode
- A supported authorization server. Veeva’s documentation states that Vault supports OpenID Connect with PingFederate, ADFS 4.0 and Okta authorization servers only. If you do not run one of these, OAuth mode is not available to you and the service-account mode is the route
- An OAuth 2.0 / OpenID Connect profile configured in Vault
- The profile’s ID — see Setup Step 2. Without it, OAuth mode cannot be used at all
Setup Guide
Vault connects two ways, and they are genuinely different — not two paths to the same place. Read this comparison before choosing.
| OAuth 2.0 / OpenID Connect | Vault username and password | |
|---|---|---|
| What License Logic stores | An OAuth client ID and client secret | A Vault service-account user name and password |
| Requires | PingFederate, ADFS 4.0 or Okta as your authorization server, plus a configured OAuth/OIDC profile | A dedicated Vault user account with API access |
| Where the token is issued | At your own authorization server, then exchanged with Vault for a session | By Vault itself |
| Best suited to | Organisations that already centralise API authentication on one of the three supported servers | Unattended, scheduled reading — the simpler route, and the one that works without a supported authorization server |
Which should you choose? If you run PingFederate, ADFS 4.0 or Okta and already manage API credentials there, use OAuth: your identity team keeps control and there is no password involved. If you do not, the service account is not a lesser option — it is the supported way in, and the section below is explicit about what it means.
Common step: create the account the integration runs as
This must be a dedicated service account, never a named person. API calls run with that account’s permissions, so binding the integration to an individual gives it that person’s access to your Vault — and the connection breaks the day they leave, change role, or have their password reset. Create an account used only for this, with a permission set granting API access and no more than the read access the integration needs.
Option A: OAuth 2.0 / OpenID Connect
Step 1: Configure the profile in Vault
In Vault, go to Admin → Settings → OAuth 2.0 / OpenID Connect Profiles and create a profile for your authorization server. You will give it a Label and a Name, and set its status to Active.
Step 2: Note the profile ID
Do not skip this. The profile identifier is part of the URL path Vault uses to exchange your access token for a session — the request goes to
login.veevavault.com/auth/oauth/session/{profile id}. Without it there is no request to make, so OAuth mode cannot be used at all. It is an identifier in a URL, not a secret.
Take it from the profile you created in Step 1 — it is the profile’s Name, which typically looks like oauth_oidc_profile__c.
Step 3: Obtain the client ID and secret
These are issued by your authorization server — PingFederate, ADFS or Okta — for the client that will represent License Logic, not by Vault. Your identity team creates them.
Option B: Vault username and password
Step 1: Create the service account
Create a dedicated Vault user for the integration, following the warning above. Assign it a permission set that grants API access and the read access it needs, and no more.
Step 2: Set a password you can hand over deliberately
Set the account’s password. If your Vault expires passwords on a schedule, consider whether this account should be exempt — when its password expires, the connection stops and must be re-entered.
Be clear about what this mode means. In this mode License Logic stores a Vault user name and password. Both are encrypted at rest and neither is ever displayed back to anyone, but this is a real credential that can sign in to Vault as that account — which is precisely why it must be a dedicated service account with narrow permissions and never a person’s login. OAuth mode avoids this by design, which is why it is offered first where it is available.
Final step: connect in License Logic
- In License Logic, click Integrations in the left sidebar
- Find the Veeva Vault tile and click Connect
- Enter your Vault DNS — hostname only, with no
https://and no trailing slash - Choose your authentication method: OAuth 2.0 / OpenID Connect or Vault username and password
- For OAuth, also enter the OAuth/OIDC profile ID from Option A Step 2, then the OAuth Client ID and OAuth Client Secret
- For the service account, enter the API user name and API user password
- Click Connect
| Field | Mode | What to enter |
|---|---|---|
| Vault DNS | Both | yourcompany.veevavault.com. Hostname only. Required |
| OAuth/OIDC profile ID | OAuth | The profile Name from Admin → Settings → OAuth 2.0 / OpenID Connect Profiles. Not a secret, but OAuth mode cannot work without it |
| OAuth Client ID | OAuth | Issued by your authorization server. Stored encrypted |
| OAuth Client Secret | OAuth | Issued by your authorization server. Stored encrypted; never shown again |
| API user name | Password | The dedicated service account. Stored encrypted |
| API user password | Password | That account’s password. Stored encrypted; never shown again |
Switching modes replaces the stored credentials. If you connect with a password and later reconnect using OAuth, the stored user name and password are overwritten with null rather than left behind — the old credential genuinely leaves the database instead of lingering behind a flag. Only one complete pair is ever held.
What Data Is Synced
Users and licence type
Vault answers this through VQL, its SQL-like query language, against the users object. The field that matters is the user’s licence type, which Vault describes as the first level of access control applied to a user — and which is what your Veeva agreement is priced on.
Vault’s six licence types:
| Licence type | Typically |
|---|---|
| Full User | A full-cost seat — the one worth reviewing |
| Read-only User | Lower cost; read access without authoring |
| External User | Collaborators outside your organisation |
| Portal User | Portal access only |
| Site User | Clinical site personnel |
| Learner | Training access |
Alongside the licence type, the sync reads each user’s name, email address (the join key to your employee records), status, and security profile.
Licence type and security profile are two different things, and both matter. Vault applies the licence type as the first level of access control and the security profile’s permission sets as the second. The licence type is what you pay for; the security profile is what the person can do within it. License Logic reads both, because a Full User with a minimal security profile is usually the clearest reclaim candidate on the list.
Where the purchased number comes from. Veeva does not publish an endpoint reporting how many seats you have bought — only who currently holds one. So the assigned side comes from the API and the purchased side comes from your Veeva contract in License Logic. That combination still answers the question that matters (bought against used); it is just worth knowing which half comes from where, particularly if your contract record is out of date.
Read-only, and narrow. The integration reads user records. It reads no documents, no document content, no binders, no regulated records and no audit trails, and it writes nothing. Vault remains your system of record; License Logic is a consumer of its user list only.
Where Your Veeva Vault Data Appears
Veeva Vault data lands in the places you already use to answer licence questions, rather than in a separate Veeva Vault area you would have to remember to visit.
Applications
Your Veeva row on the Applications page shows licence facts rather than sign-in counts:
- Total licences — the seats you hold, sourced from the Veeva Vault API rather than typed in by hand
- Assigned — how many of those seats are actually allocated to a person
- Breakdown by licence type — entitled against assigned, per licence, ordered so the largest gap is first. That top row is the one worth acting on, and it is rarely the alphabetically-first one
- Idle seats — the difference, which is the number that converts into a renewal conversation
Application drill-down
Opening Veeva shows every user with their licence type and security profile. Full Users are the expensive row, so they sort to the top of a reclaim review rather than being buried among read-only and site users.
Insights → Employee
Each employee’s record gains Veeva Vault as a source alongside SSO sign-in, desktop agent and card-spend data. Opening a person shows the applications they hold, so a leaver review or a role change can see the Veeva Vault seat in the same place as everything else they hold.
Suppliers and renewals
Because seat counts arrive as data rather than as a number someone typed into a contract, your Veeva Vault agreement can be compared against actual allocation as the renewal approaches — which is the moment the difference is worth money.
Licence types are counted separately, not summed. A single total spanning all six licence types is not a number anyone can act on — Full Users and Learners do not cost the same and are not interchangeable. The breakdown is what makes the figure usable.
Two switches, not one. A tenant needs the integration connected and the licence display enabled for it. That is deliberate: it stops a seat panel appearing for a tenant whose connection cannot actually compute one, which would show an empty panel rather than an honest absence. We enable both together and tell you when we have.
Sync Schedule & Refresh
Daily sync
License Logic reads Veeva Vault once per day, overnight UTC, in the same window as our other licence integrations. Each run replaces the previous day’s picture, so revoked seats and new assignments are both reflected without anything to reconcile by hand.
Initial sync
Your first sync is scheduled once your connection is confirmed. It reads user records only, so it completes quickly regardless of how many documents your Vault holds.
What triggers a sync
- Initial connection — your first sync is scheduled once your connection is confirmed
- Daily scheduled sync — automatically, once per day
- Reconnection — reconnecting with new credentials resumes syncing on the next scheduled run
A failed sync leaves yesterday’s data in place. If a run cannot complete — Veeva Vault is unreachable, or the credential has been revoked — License Logic keeps the previous successful result rather than emptying the panel. “This tenant has no licences” and “we could not read them today” look identical on screen, so we never let a failure produce the first one.
A password-mode connection needs its password kept current. If your Vault expires service-account passwords on a schedule, the sync stops at that point and resumes once the credential is re-entered. Exempting the service account from expiry, where your policy allows it, avoids a recurring interruption.
Disconnecting Veeva Vault
Disconnecting deletes your stored Veeva Vault credentials. They are removed from the database outright, not disabled behind a flag, so reconnecting means entering them again, and any data already synced is removed with them. Your Veeva Vault account itself is untouched, but you may need to issue a new credential there if you did not keep the original.
To disconnect:
- Go to Integrations in the left sidebar
- Find the Veeva Vault tile (showing “Connected”)
- Click Disconnect
- Confirm in the dialog
Revoking from the Veeva Vault side
For the service-account mode, disable the Vault user or change its password — either stops the connection immediately. For OAuth, revoke or rotate the client credentials at your authorization server, or set the OAuth profile in Vault to inactive. Removing the account’s API permission set also stops it.
Revoking on the vendor side and disconnecting in License Logic are independent. Doing both is the complete removal: one stops the credential working, the other removes our copy of it.
Security & Data Handling
What License Logic holds
It depends on the mode you chose, and the difference is worth stating plainly. In OAuth mode, License Logic holds an OAuth client ID and client secret issued by your own authorization server, plus your OAuth profile ID — no password is involved. In service-account mode, License Logic holds a Vault user name and password. Both values are encrypted at rest and neither is ever returned by any License Logic interface, but this is a credential that can sign in to Vault as that account, which is why the setup guide insists it be a dedicated service account with narrow permissions rather than a person’s login.
| Control | Detail |
|---|---|
| Encryption at rest | AES-256-GCM with a random initialisation vector per value, applied before the value is written to storage |
| In logs | Never written. Connection events are logged with the credential values redacted |
| Retrievable via API | Never returned — not even to your own administrators. The connection-status endpoint is built from the non-secret fields only, so a secret cannot be read back through it |
| In transit | TLS 1.2 or above, passed in a request header or form body. Never placed in a URL or query string |
| Who can connect or disconnect | Only a user holding Settings: Edit in your License Logic tenant |
| Who can see the connection status | A user holding Integrations: View. Status shows the non-secret settings, whether the connection is verified, and when it was made |
| Tenant scope | Stored against your License Logic tenant. Connect, status and disconnect are all keyed on the caller’s own tenant, so no request from another customer can reach your connection |
| Only one credential pair is held | Vault stores exactly one complete pair. Reconnecting in the other mode writes null over the pair you are leaving, so a replaced password actually leaves the database rather than lingering behind a flag |
| Permissions the credentials carry | Those of the Vault account the integration runs as, as enforced by Vault’s permission sets. License Logic cannot widen this — if you want to narrow what we could ever see, narrow the permission set |
Verification on connect
License Logic does not verify this credential on connect. There is no published Veeva Vault endpoint we have been able to read our own documentation for, so there is nothing we can call that would tell you something true. Your credentials are stored and the tile shows them as saved, not yet confirmed.
This is a deliberate choice over the alternative. A check written against a guessed endpoint reports a good credential as unverified, and then nobody can tell whether the credential or the guess was wrong. An honest “we have not confirmed this” is more useful than a red mark that means nothing.
Access control
- Settings: Edit is required to connect or disconnect
- Integrations: View is required to see the Integrations page and connection status
- All endpoints are authenticated through your License Logic session
Data retention
Credentials are retained until you disconnect, at which point they are deleted from the database outright rather than disabled behind a flag.
Disabling the Vault account, changing its password, or revoking the OAuth client at your authorization server all stop the connection immediately, whether or not you also disconnect in License Logic. Doing both is the complete removal.
A note on what other License Logic integration documents say
Other integration documents from us state that the integration in question holds only application credentials and never a person’s sign-in. Those statements are accurate where they appear and are scoped to the integration they describe — Agiloft, for example, uses OAuth client credentials only. Do not read them as a platform-wide guarantee: Veeva’s service-account mode is an exception, and we are not going to let that pass unstated. If holding a Vault credential of this kind is unacceptable to your security team, OAuth mode is the alternative, subject to your running one of the three supported authorization servers.
For more about License Logic’s security practices, see our Security Policy or contact security@licenselogic.co.
Troubleshooting
The tile will say “saved, not yet confirmed”, and that is correct. License Logic does not test Veeva credentials at connect time — see Security & Data Handling for why. A connection that shows as unconfirmed is not a fault and does not need reporting.
We are not sure the Vault DNS is right
Vault does not simply reject a wrong DNS, which makes this worth double-checking. Veeva’s documentation states that if you authenticate against a DNS the user does not have access to, Vault issues a session for that user’s most relevant available Vault instead — preferring their last login location, then their oldest active Vault membership. Authentication appears to succeed while addressing a different Vault. Confirm the DNS with your Vault administrator rather than assuming a successful sign-in proves it.
Which value is the OAuth profile ID?
It is the Name of the profile at Admin → Settings → OAuth 2.0 / OpenID Connect Profiles, not its Label and not your client ID. It typically ends __c. If you supply the Label by mistake, OAuth mode cannot address the right profile.
OAuth is not offered by our identity platform
Veeva supports OpenID Connect with PingFederate, ADFS 4.0 and Okta authorization servers only. If yours is not one of those, use the service-account mode — it is the supported route, not a workaround.
The connection worked and then stopped
- The service account’s password expired or was reset. This is the most common cause. Reconnect with the current password, and consider exempting the account from password expiry
- The account was disabled or deprovisioned, or lost its API permission set
- The OAuth profile was set to inactive, or the client credentials were rotated at your authorization server
- Authentication was rate-limited. Vault limits authentication calls per user name and domain against your configured burst limit
Connected, but no data has appeared yet
Your first sync is scheduled once your connection is confirmed, so data appears shortly after rather than the instant you click Connect. If nothing has appeared after your first scheduled sync, contact support and we will look at the run.
The Connect button does nothing, or the tile is missing
This is almost always permissions on the License Logic side. Integrations: View shows the page; Settings: Edit is required to connect. Ask your License Logic administrator to check both in People → Roles.
Frequently Asked Questions
Does License Logic store a Veeva password?
In service-account mode, yes — a dedicated Vault service account’s user name and password, encrypted at rest and never displayed back to anyone. In OAuth mode, no: we hold an OAuth client ID and secret issued by your own authorization server. We say this explicitly because it is the kind of thing a security review should not have to discover for itself.
Why is a password an option at all?
Because for many Vault customers it is the only option. Veeva supports OpenID Connect with PingFederate, ADFS 4.0 and Okta only. Without one of those, a Vault user name and password is the supported way to authenticate to the API.
Why must it be a service account rather than a real user?
Three reasons. API calls run with that account’s permissions, so a person’s login gives the integration that person’s access. The connection breaks whenever their password is reset or their account is disabled. And a shared human credential is exactly what your own access policies are likely to prohibit. A dedicated account with a narrow permission set avoids all three.
Can License Logic change anything in our Vault?
No. The integration reads user and licence information. It does not create, edit or delete documents, records, users or configuration. Today it does not read anything at all.
Why does the tile not confirm our credentials?
Because we have not found a Veeva endpoint we could call that would tell you something true. Writing a check against a guessed endpoint would report good credentials as unverified, and then nobody could tell whether the credential or our guess was wrong. In password mode there is a second reason: a check would send your service account’s password to the host typed on the line above it, before anyone had confirmed that host is yours.
Can we switch from password to OAuth later?
Yes. Reconnect and choose the other mode. The credentials from the mode you are leaving are overwritten with null, so only the pair you are now using is held.
What happens if we disconnect?
The stored credentials are deleted from License Logic, and any Veeva Vault data already synced is removed with it. Your Veeva Vault account itself is untouched — the connected app remains valid there until you revoke it.
Support
If you need help with the Veeva Vault integration:
- Email: support@licenselogic.co
- In-app chat: click the chat icon in the bottom-right corner of License Logic
- Security questions: security@licenselogic.co
When contacting support, please include your company name, your Vault DNS and which authentication mode you chose, and a description of the issue. Never send a credential by email — if we need to look at a connection, we can do so from our side.
If you would like to be told when the sync for this integration is enabled, say so and we will add you to the notification list for it.