> 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.md).
# Attributes
What Userlane knows about a person beyond their clicks, how attributes arrive, and how they are used.
Attributes describe the person. Audiences[^1] are the rules built from them, and together the two make it possible to show the right content to the right people and to read analytics for one group rather than the whole workforce.
Every attribute has three parts. The **name** is the key that values arrive under. The **title** is the display label shown in the portal. The **data type** fixes what kind of value the attribute can hold, and it is set once at creation and cannot be changed afterwards.
The name and the title do not have to match. An attribute named `dept_code` can carry the title Department, which is why the portal shows both columns.
| Data type | Holds | Example value |
| ------------- | --------------------------- | ------------------- |
| Text | A string of text | Finance |
| Number | A whole number or a decimal | 5 |
| True/false | A boolean value | true |
| List | Several values at once | Sales, Marketing |
| Date and time | A timestamp | 2026-03-14 20:12:55 |
Every attribute also has a scope. A company-scoped attribute applies to every application in the account. An application-scoped attribute applies to one application only, which matters when different applications hold different values for the same person.
## Where attribute values come from
Values can reach Userlane in several ways, and more than one can run at the same time. [Attribute sources](/administration/attributes/attribute-sources.md) compares them in detail.
**Connected source systems** are the most hands-off option. [Connect a supported system](/administration/attributes/connect-an-attribute-source.md) on the **Attribute sources** page and values arrive on a schedule: usually within about fifteen minutes the first time, then overnight, once a day. 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 before the connection can be made. Connecting a source creates the attributes it provides automatically, and if an attribute with the same name already exists, the connection writes into it and overwrites whatever was there on every sync. Once connected, the source system becomes the place to maintain those attributes: changes made by hand in Userlane are replaced by the next sync, so corrections belong in the source system. Connectors always write at company level. If you need a value that applies to one application only, use the API or the snippet[^2] instead.
**The Attribute Import API** (application programming interface) covers everything the connectors do not. [Push values](/developer-reference/push-user-attributes-via-api.md) from any system, including in-house applications, data warehouses, or anything your team can export from. A request can carry the attribute definition alongside the values, so the attribute is created automatically. The API also does two things connectors cannot: it can target a single application rather than the whole account, and it can remove or replace values rather than only adding them.
**Single sign-on (SSO)** carries values in the login process. When someone signs in, the identity provider passes whatever fields the identity team chose to map, and attributes are created automatically from the provider as named there. That is often fewer fields than the directory actually holds, and the values only refresh when the person signs in again, so they can go stale. If you want the same directory data without that limitation, connect your identity provider as a source system instead. See [Attributes from SSO](/administration/attributes/attributes-from-sso.md).
**The snippet** suits information your own application already knows, such as a license tier or an in-app role. The application passes values with the `identify` [command](/developer-reference/quick-reference-of-commands.md) when the snippet loads. Unlike every other source, **the snippet does not create attributes automatically.** Create the attribute in the portal first, or the value is discarded without an error and nothing in the portal shows that it arrived. When developers add attributes to the `identify` command, agree the attribute names first and create them in the portal to match.
**Comma-separated values (CSV) upload** is the fastest way to get started. [Upload a list](/administration/attributes/upload-attributes-manually.md) of users and their attribute values directly. Missing attributes can be created while mapping the file. It is also the only source that goes stale on its own: a list is accurate on the day it goes in, and nothing tells you when it no longer reflects reality.
## What attributes are for
Attributes let you see how a particular group is doing, act on what you find, and check whether it worked. Without them, each of those steps happens at the level of the whole workforce, which is rarely where the problem is.
An adoption figure of sixty-two percent reads as acceptable. Split by department it turns out to be ninety percent in finance and twenty percent in the warehouse, and now there is something to do: the warehouse team needs support that finance does not, and it can be put in front of them without interrupting anyone else. At the next review the same split shows whether it worked.
Attributes filter HEART[^3] and adoption figures so results split by the groups you actually manage, and they target content so a guide, announcement, or validator reaches one group and not another.
Three patterns account for most of what people build.
**Splitting adoption by group.** Department, location, and job title turn one workforce average into figures a manager can act on. This is the most common reason organizations connect a source system rather than relying on sign-in data alone.
**Excluding people who should not see content.** Contractors, administrators, and read-only users often need to be kept out of onboarding guides and feature announcements. An employment type or role attribute makes that exclusion a rule rather than a manual list.
**Targeting by experience.** Hire date and prior content interaction separate new joiners from established staff, so onboarding content reaches the people who need it and stops reaching the people who do not.
## Attributes and audiences
| | Attribute | Audience |
| ------------------------- | ---------------------------------------------------------------------- | --------------------------------------- |
| What it is | A single fact about a user | A rule combining attribute conditions |
| What it resolves to | One value per user | A group of users |
| Where it comes from | A connected system, the API, single sign-on, an upload, or the snippet | Built in the portal |
| What it can be applied to | Nothing directly | Content targeting and analytics filters |
Targeting a group always means [building an audience](/administration/audiences/build-an-audience-from-attribute-rules.md) first, even when that audience uses a single condition.
## How values behave
A few things about attribute values are worth knowing before you start building audiences from them.
Values arrive exactly as the source holds them. A department might be `Sales` in one system and `SALES_DE` in another, and Userlane treats those as two different values. Values are also matched case-sensitively by default: if a source sends `Admin` and the audience filters for `admin`, the audience will not match. The audience builder has a setting to turn case sensitivity off. If an audience matches nobody and the values look right, that setting is the first thing to check.
A connection reads your directory using the permissions of whoever authorized it. If those permissions are narrow, some fields come back empty, and the connection does not report an error. This is why an attribute can be mapped and still show no values for some or all people.
Connected sources add and update values, but they never remove them. If a source system stops providing a value, the last value Userlane received stays in place. Only the Attribute Import API can delete a value. If values have disappeared, start with whatever calls the API.
When 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. In practice this rarely matters, because different sources usually populate different attributes, but it is worth checking when two sources hold the same field and disagree about it.
## In this section
Connect an attribute source
How connectors work, what Userlane reads, and the setup steps for each supported system.
{% columns %}
{% column width="50%" %}
{% content-ref url="/pages/heUmxS6HxlGKqCQSjqbs" %}
[Attribute sources](/administration/attributes/attribute-sources.md)
{% endcontent-ref %}
{% content-ref url="/pages/eDKAypFN3hxD4iC2VJll" %}
[Attributes from SSO](/administration/attributes/attributes-from-sso.md)
{% endcontent-ref %}
{% endcolumn %}
{% column width="50%" %}
{% content-ref url="/pages/AUQVzJX0D3SRWDT6AOgS" %}
[Upload attributes manually](/administration/attributes/upload-attributes-manually.md)
{% endcontent-ref %}
{% endcolumn %}
{% endcolumns %}
{% hint style="info" %}
**Looking for something else?**
Try [Audiences](/administration/audiences.md), [Targeting](/assistance/content-operations/targeting.md), or [Push user attributes via API](/developer-reference/push-user-attributes-via-api.md).
{% endhint %}
## Relevant articles
{% content-ref url="/pages/TKBRGmMaapWk0xuF3XwG" %}
[Audiences](/administration/audiences.md)
{% endcontent-ref %}
{% content-ref url="/pages/Zk1PSRimln0YLI1l2ZkI" %}
[Build an audience from attribute rules](/administration/audiences/build-an-audience-from-attribute-rules.md)
{% endcontent-ref %}
{% content-ref url="/pages/BkK6BtMQAoCXdpgXSBa5" %}
[Targeting](/assistance/content-operations/targeting.md)
{% endcontent-ref %}
{% content-ref url="/pages/NFn4yfhEX6UQ4Oy1WPAW" %}
[Audiences: design, test, and keep them accurate](/best-practices/audiences-design-test-and-keep-them-accurate.md)
{% endcontent-ref %}
## FAQ
What is a user attribute in Userlane?
A user attribute is a fact about a user, such as department, job title, location, or employment status. Each attribute has a name, a title, and a data type. Userlane uses attributes to build audiences, which target content and filter analytics.
Is an attribute the same as an audience?
No. An attribute is a single fact about one user. An audience is a rule built from attribute conditions that resolves to a group of users. Content and analytics filters are applied to audiences, not to attributes directly.
What data types can an attribute have?
An attribute can be **Text**, **Number**, **True/false**, **List**, or **Date and time**. The data type is set when the attribute is created and cannot be changed afterwards.
Does the snippet create attributes automatically?
No. The snippet is the only source that requires the attribute to exist in the portal before values are accepted. Connected source systems, the Attribute Import API, CSV upload, and SSO all create attributes automatically.
What happens when two sources provide different values for the same attribute?
The most recent value wins. There is no priority ordering between sources. Check the values that arrived if two sources hold the same field and disagree about it.
[^1]: An audience is a reusable group defined by attribute conditions. Audiences control who sees which content and how analytics filter.
[^2]: The snippet is the JavaScript code that loads Userlane inside a single application, as an alternative to the browser extension.
[^3]: HEART is Userlane's five-dimension model for scoring how well an application works for the people using it, on a scale of 0 to 100.
---
# 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.md?ask=&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.