Alex Johnson avatar
Written by Alex Johnson
Updated over a week ago

Which of Vendr's products is this article applicable to?


  • Vendr 2.0

Not Applicable

  • Freemium

  • Premium Intelligence

  • Premium Procurement

About People

The People page shows you all the people in your organization, according to what the data sources you have connected to your Vendr account can see.

Admin Only:

The People page is only viewable by users with Admin permissions.

People Table

This is the main view of this page and shows a variety of information, across a number of tabs.

Some tabs are locked, which means that Vendr maintains those views as standard/default views across all accounts.

If a view is not locked, then you're able to adjust the view to your own specifications (filters, columns, etc).

  • Sources: Every source encountered for spend and access (i.e. Gmail, Vendr, Quickbooks, Bank/Credit card etc).

  • Download: Allows you to download information from this view into a CSV.

  • Columns: Allows you to customize the columns in this report view

People Properties

Every Person record in your Vendr account has associated Properties that you can use to keep track of various pieces of metadata. You can create Custom People Properties, but the default ones are:

  • Name - can be sourced automatically from our IdP integrations, or entered manually

  • Email - can be sourced automatically from our IdP integrations, or entered manually

  • Title

  • Account Type - 4 options:

    • Contractor

    • Employee

    • Service Account

    • Unknown

  • Manager - can be sourced automatically from our HRIS integrations, or entered manually

What is a Service Account?

One of the options for Account Type is Service Account.

A Service Account is typically a user account you create in a system that isn’t tied to an actual person.


If you have Okta and you want to connect it to your Vendr account via our Okta IdP Integration, part of that process involves creating an API token for Vendr inside Okta.

If you create that token using a regular user account, and then that user account gets deactivated (for example, the person leaves the company), then your API token you created with that role will break.

So instead, you create the API token with a service account (eg., [email protected]) so that the token isn’t tied to an actual person.

It’s still technically a user account, but because it’s not tied to an actual person, we use the term “service account” to note the distinction.

Did this answer your question?