> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/administration/attributes/attribute-sources.md).

# Attribute sources

Where attribute values come from, what each source is for, and how to choose between them.

An attribute source is anywhere attribute values come from. Userlane accepts values from five sources, and you can use as many as you need at the same time.

## The five sources

<table><thead><tr><th width="161.03515625">Source</th><th width="326.1597900390625">Best for</th><th>Who sets it up</th></tr></thead><tbody><tr><td><strong>Connected systems</strong></td><td>Keeping attributes current automatically from the system that owns them</td><td>A Userlane administrator, plus an administrator of the source system</td></tr><tr><td><strong>Attribute Import API</strong></td><td>Any system Userlane does not connect to, and anything your team can export</td><td>Your engineering or data team</td></tr><tr><td><strong>Single sign-on</strong></td><td>Attributes your identity team already maps into sign-in</td><td>Whoever manages the single sign-on configuration</td></tr><tr><td><strong>The snippet</strong></td><td>Values your own application already knows about the signed-in user</td><td>Whoever maintains the application</td></tr><tr><td><strong>CSV upload</strong></td><td>A one-off list, or getting started before anything is automated</td><td>A Userlane administrator</td></tr></tbody></table>

<div data-with-frame="true"><figure><img src="https://259567114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF6bxg8i3T6U4vZ3k7PHi%2Fuploads%2FaTkXNnkX5uNQOZXa7YwH%2Fattributes.png?alt=media&#x26;token=3cfc9662-5ae1-4492-895c-6b9bdffc3c96" alt="The Attribute sources page in the portal settings, showing the systems available to connect"><figcaption><p>The <strong>Attribute sources</strong> page in the portal settings.</p></figcaption></figure></div>

### Connected systems

Connect a system once on the **Attribute sources** page in your settings, and Userlane reads attributes from it on a schedule from that point on. Six systems are supported: [SAP SuccessFactors](/administration/attributes/connect-an-attribute-source/sap-successfactors.md), Microsoft Entra ID, [Google Workspace](/administration/attributes/connect-an-attribute-source/google-workspace.md), [Salesforce](/administration/attributes/connect-an-attribute-source/salesforce.md), [ServiceNow](/administration/attributes/connect-an-attribute-source/servicenow.md), and [Jira](/administration/attributes/connect-an-attribute-source/jira.md).

An administrator of that system completes a one-time setup step there first and authorizes the connection. The first values usually arrive within about fifteen minutes, then refresh every 24 hours.

Three things are true of every connection:

* It only reads. Userlane never writes to the source system or changes anything in it.
* It only updates people who already exist in Userlane. Nobody is created.
* It never removes a value. If the source system stops providing one, the last known value stays.

Connections apply to the whole account rather than to a single application.

This is the right choice when the information lives in a system Userlane supports and you want it to stay current without anyone maintaining it. See [Connect an attribute source](/administration/attributes/connect-an-attribute-source.md) for setup steps.

### Attribute Import API

Your team pushes values to Userlane from a data warehouse, an internal service, or a scheduled job through the Attribute Import application programming interface (API). It works with anything you can export from, so it covers every system Userlane does not connect to directly. For the request format, see [Push user attributes via API](/developer-reference/push-user-attributes-via-api.md).

It also does two things connectors cannot: it can target a single application rather than the whole account, and it can replace values rather than only adding them.

This is the right choice when your system is not one Userlane connects to, when you already run a data pipeline, or when you need attributes that apply to one application only.

### Single sign-on

Attributes arrive as claims in the Security Assertion Markup Language (SAML) assertion[^1] when someone signs in through single sign-on (SSO). Whatever the identity team has mapped comes through automatically.

Two things are worth knowing. SSO only passes the fields the identity team chose to map, which is often fewer than the directory actually holds. And values only update when someone signs in and sees the authentication prompt, so they can go stale for people who have not signed in recently.

This is the right choice when the attributes you need are already mapped into the SSO configuration. If you want the same directory data without the sign-in dependency, connect the identity provider as a source instead. See [Attributes from SSO](/administration/attributes/attributes-from-sso.md).

### The snippet

The application passes values with the `identify` [command](/developer-reference/quick-reference-of-commands.md) when the snippet[^2] loads. This suits information the application knows that no human resources (HR) system or directory does, such as a license tier or an in-app role.

The attribute has to exist in Userlane before values will be accepted, and values need to be sent before or at the moment the snippet initializes. Anything sent later may arrive after a targeting rule has already been evaluated.

This is the right choice when the application holds the information and Userlane is embedded in it.

### CSV upload

[Upload a list](/administration/attributes/upload-attributes-manually.md) of users and their attribute values directly as a comma-separated values (CSV) file.

CSV upload is the fastest way to get started and the only source that goes stale on its own. A list is accurate on the day it goes in, but people change roles and teams reorganize, and nothing tells you when the file no longer reflects reality.

This is the right choice when you want to try something quickly, or for a set of values that genuinely does not change.

## Using more than one source

Most organizations end up using two or three sources, because no single system holds everything. An HR system knows department and manager, your own application knows the license tier, and the identity provider covers people the HR system does not.

If two sources provide a value for the same attribute and the same person, the most recent value wins. There is no ordering between sources, so a value from one source can replace a value from another. In practice this matters less than it sounds, because different sources usually populate different attributes. It is worth checking when two sources both hold the same field and the values disagree.

### Choosing where to start

If you are setting Userlane up for the first time, the useful question is not which source to use but where the information you need actually lives. Job title and department usually sit in an HR system. Whether someone is a contractor might sit in the same place or in the identity provider. A license tier probably only exists in the application itself.

Work through the attributes you want to target or report on, decide which system is the authority for each, then pick the source that reaches it. Your Userlane contact can help with this, and it is worth doing before anyone connects anything.

## Relevant articles

{% content-ref url="/pages/gtcOzAVjL7zzv75As2Jd" %}
[Attributes](/administration/attributes.md)
{% endcontent-ref %}

{% content-ref url="/pages/5RV9H7dUyIbkTHBrF8Av" %}
[Connect an attribute source](/administration/attributes/connect-an-attribute-source.md)
{% endcontent-ref %}

{% content-ref url="/pages/eDKAypFN3hxD4iC2VJll" %}
[Attributes from SSO](/administration/attributes/attributes-from-sso.md)
{% endcontent-ref %}

{% content-ref url="/pages/AUQVzJX0D3SRWDT6AOgS" %}
[Upload attributes manually](/administration/attributes/upload-attributes-manually.md)
{% endcontent-ref %}

{% content-ref url="/pages/ZTVMq8E5zKZ7JFbGC4gI" %}
[Push user attributes via API](/developer-reference/push-user-attributes-via-api.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>Can more than one source provide the same attribute?</summary>

Yes. If two sources provide a value for the same attribute and the same person, the most recent value wins. There is no priority ordering between sources.

</details>

<details>

<summary>Does Userlane write back to connected systems?</summary>

No. Every connection is read-only. Userlane never writes to, modifies, or deletes anything in a connected system.

</details>

<details>

<summary>How often do connected systems sync?</summary>

The first values usually arrive within about fifteen minutes after the connection is set up. After that, values refresh every 24 hours.

</details>

<details>

<summary>Do attributes need to exist before values arrive?</summary>

It depends on the source. Connected systems and the Attribute Import API create attributes automatically. The snippet requires attributes to exist in the portal first, and silently discards values for attributes it does not recognize.

</details>

[^1]: A SAML assertion is the data package an identity provider sends when someone signs in through single sign-on. It can include user attributes such as department, role, or location alongside the authentication credentials.

[^2]: The snippet is the JavaScript code that loads Userlane inside a single application, as an alternative to the browser extension.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/administration/attributes/attribute-sources.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.