Three simple ideas sit behind the name: a profile, a source, and a ranking.

Okta keeps one record for every person, stored in a place called Universal Directory. That record is called a profile. A profile is like an identity card that holds attributes, which are named pieces of information such as first name, email, department, job title, manager, and start date. Every app that Okta connects to reads from this card.

A profile source is any system that is allowed to feed information into that card. Common examples are an HR system such as Workday, a directory such as Active Directory, or another business app that Okta can import people from. Okta itself can also be a source, when administrators or people edit the profile directly.

Profile source priority is the ranking you give to those sources. When more than one system claims the same person, the ranking tells Okta whose version of the profile to trust first. In short, it answers one question: when two systems disagree, who wins?

Three questions it helps you answer

Everyday phrases and what they really mean

Identity teams use short phrases that can confuse newcomers. Knowing them saves time in meetings. When someone says “HR is the master”, they mean that the HR system is the source whose values win for the attributes it owns. When they say “Okta is mastered by the directory”, they mean the profile is filled mainly from directory data. When they say “the import overwrote it”, they mean a source wrote a value that replaced one already stored.

Another common phrase is “flapping”, which describes a value that keeps switching between two answers. A “stale” value is one that no longer matches reality because the source stopped updating it. An “orphan” is an account whose source record has vanished, leaving nobody responsible for it. Spotting these three words in a log or a ticket quickly tells you what kind of problem you face, and which part of this guide to open first.

Finally, people often say “source of truth” when they really mean “the system I trust most”. Be gentle with the phrase. Truth in identity data is rarely about one system being right about everything. It is about agreeing, in writing, which system answers which question, and holding every other system to that agreement.

Every rule exists because something went wrong without it. Here is what goes wrong without clear priority.

In a small company, one system usually knows everyone. As the company grows, it adds a dedicated HR system for contracts and pay, a directory for computers and logins, and special systems for contractors, students, or partners. Each is correct about its own corner of the business. None of them is correct about everything.

Now connect them all to Okta. Each source sends updates on its own schedule. If there is no ranking, whichever source ran last overwrites the profile. This causes a quiet but damaging problem called flapping, where a value keeps switching back and forth as different sources take turns writing it.

What goes wrong without a ranking

Why this matters even for small teams

Some teams believe ranking is only for giant enterprises. In truth, trouble starts as soon as a second people system appears. A startup that adds a payroll tool beside its directory already has two voices describing the same employees. The earlier the ownership rules are written, the cheaper they are to keep. Fixing a tangled profile design after five systems and three thousand users is far harder than writing a one-page ownership table on the day the second system arrives.

The habit is also cheap to start. Pick the five attributes that drive access, name one owner for each, and record the answer where the whole team can read it. That small exercise already removes most of the confusion, and it prepares you for the day a merger, a new HR platform, or an audit makes the question urgent.

A short vocabulary list makes the rest of this guide much easier to follow.

Identity work has its own words. Most of them describe either where data comes from, or who is allowed to change it. The table below puts the key terms next to a simple picture.

Source of truth, explained

The phrase source of truth means the one system whose answer is final for a given piece of data. For a hire date, that is almost always the HR system. For a login name, that may be the directory. For a preferred display name, it may be the person themselves. A healthy design names a source of truth for every attribute that matters.

Priority versus ownership

Priority is the ranking between sources. Ownership is the decision about who may change a value at all. They work together. Ownership says the HR system is allowed to set the job title. Priority says that if two systems both try, the higher-ranked one wins. A good design uses both: clear owners most of the time, and a clear ranking for the rare disagreements.

Here is the full picture of how profile data flows in, gets ranked, and flows back out to apps.

The design has three layers. On the left are the profile sources, which send people and attributes into Okta. In the middle is Okta, where matching, priority, and sourcing rules decide what the final profile looks like. On the right are the downstream apps, which read the finished profile and receive updates. Data enters ranked, and leaves clean.

flowchart LR
  subgraph Sources["Profile Sources"]
    HR["HR system"]
    AD["Active Directory"]
    CT["Contractor system"]
  end
  subgraph OktaZone["Okta"]
    MT["Matching rules"]
    PR["Priority and sourcing rules"]
    UD["Universal Directory profile"]
  end
  subgraph Apps["Downstream Apps"]
    A1["Email suite"]
    A2["Chat tool"]
    A3["Sales CRM"]
  end
  HR -->|"Import"| MT
  AD -->|"Import"| MT
  CT -->|"Import"| MT
  MT --> PR
  PR --> UD
  UD -->|"Provision and update"| A1
  UD -->|"Provision and update"| A2
  UD -->|"Provision and update"| A3

The components, one by one

Why one profile matters

Apps do not care how many sources a company has. They want one trustworthy answer. By collapsing many voices into one profile, Okta protects every connected app from the confusion. This is the biggest gift of a well-ranked design: the mess stays upstream, and the clean answer goes downstream.

Not every source deserves the same trust. Knowing each type helps you decide where it belongs in the ranking.

Sources differ in how often they change, how carefully their data is kept, and how complete they are. A good ranking reflects these real strengths. The top spot should go to the system that is most authoritative about the person, not the one that is easiest to connect.

Qualities of a strong primary source

Authority beats convenience

Teams are often tempted to rank the directory first, simply because it was connected first and everyone trusts it. But if titles in the directory are copied by hand from HR, the directory is a second-hand source. Ranking the true origin first means mistakes are fixed at the root, not patched downstream.

A ranking is only as good as the attributes it protects. Good profile design makes every later decision easier.

A profile is made of attributes, and each attribute has a name, a type, and a purpose. Okta provides a standard set of base attributes such as first name, last name, email, and login. It also lets administrators add custom attributes for anything specific to the company, such as cost center, building, or contractor sponsor. Every attribute you add is another thing that sources may write and apps may read.

Questions to ask before adding an attribute

Naming and consistency

Short, clear names save a great deal of confusion. A name such as “costCenter” tells the next administrator what the field holds. A name such as “custom1” tells them nothing. Agree a naming style, write it down, and apply it to every new attribute. Consistent names also make mappings and group rules easier to read.

Free text versus controlled values

Free text invites variation. One manager types “Finance”, another types “finance dept”, and a third types “FIN”. Group rules that look for an exact value will miss two of the three. Where possible, let the owner source supply a controlled list of values, and convert odd spellings into the standard form at the mapping step.

This chapter walks through the decision in simple steps. The exact screens vary, but the logic is steady.

When a source sends a record to Okta, Okta does not simply paste it onto a profile. It first asks which person this record describes. Then it asks how much authority this source has for that person. Only then does it decide which values to keep. The questions are always asked in this order.

flowchart TD
  R["Record arrives from a source"] --> M{"Does it match an existing user?"}
  M -->|"No"| C["Create a new user from this source"]
  M -->|"Yes"| P{"Is this source the top priority for this user?"}
  P -->|"Yes"| U["Apply this source's values as allowed by mappings"]
  P -->|"No"| L["Keep higher source values and only fill gaps if allowed"]
  C --> D["Profile stored in Universal Directory"]
  U --> D
  L --> D

The decision, step by step

Priority only works if Okta correctly knows that two records are the same human. Matching is the foundation.

An import is the process of bringing records from a source into Okta. Each record describes one person in the source’s own words. Before Okta can rank anything, it must decide whether that record belongs to a person it already knows. This decision is called matching.

Matching uses rules you choose. A rule might say “two records are the same person if their employee number is equal”, or “if their email addresses are equal”. When a rule finds a match, Okta links the new record to the existing profile instead of creating a second one. When no rule finds a match, Okta may create a new profile.

Good identifiers and bad identifiers

What a wrong match looks like

If matching is too loose, two different people are merged into one profile. One person’s title and manager then appear on another person’s account, which can grant the wrong access. If matching is too strict, the same person appears twice, and each profile fights for its own apps. Both problems look like priority problems, but the real cause lies in matching.

Good habits for matching

Two related tools help you control who wins. One works on the whole person, and the other works on single attributes.

Source priority works at the level of the person. It ranks the systems that know a person, so that one of them leads. Attribute-level sourcing works at the level of a single attribute. It lets you say that the email should come from one source, the department from another, and the preferred name from Okta itself.

A mix-and-match example

Suppose HR is the best source for job title, manager, and employment dates. The directory is the best source for the login name and technical email. Okta is best for the preferred display name, because people know how they want to be called. Attribute-level choices let each system speak where it is strongest, while priority settles disputes over any attribute you did not assign.

When to use which

Start simple. If one system is strong across the board, a clean priority order may be all you need. When a single system is weak at a few attributes, add attribute-level choices only for those. Every extra rule is something a future administrator must understand, so each one should earn its place.

Mappings control exactly which fields move, in which direction, and whether they overwrite what is already there.

Each source names its fields differently. One system says “Surname”, another says “Last Name”, and a third says “sn”. A mapping is a rule that links a field in the source to a field in the Okta profile. Without a mapping, a value simply does not travel, no matter how highly ranked its source is.

Priority decides the winner, mappings decide the details

This point surprises many people. A source can be the top priority and still change nothing if its mappings are empty. In the same way, a lower-ranked source with many mappings can fill gaps that the top source never maps. Always read priority and mappings together when you investigate a value.

Questions to answer for every mapping

Transformations in simple terms

Sometimes a value must be changed on the way in. For example, a source may store a full name in one field, while Okta wants first and last name separately. Or a department code such as “FIN” may need to become “Finance”. Okta provides ways to transform values during mapping. Keep these transformations small and well documented, because hidden logic is the hardest to debug later.

Real life is messier than a diagram. Here are the situations that most often force a priority decision.

Each scenario below shows a common clash and the thinking that resolves it. The companies are fictional teaching examples, but the patterns appear again and again.

A simple conflict checklist

Follow one person from hiring to leaving, and watch where the ranking takes part.

Identity teams describe a person’s time at a company in three stages. A joiner is a new hire, a mover is someone whose role changes, and a leaver is someone who departs. At each stage, a source starts the change, Okta applies the priority rules, and apps receive the result.

sequenceDiagram
  autonumber
  participant H as HR system
  participant D as Directory
  participant O as Okta Universal Directory
  participant A as Downstream apps
  H->>O: New hire record arrives
  O->>O: Match to a person and apply priority
  O->>D: Provision the directory account
  D-->>O: Account details imported back
  O->>A: Provision apps based on profile and groups
  H->>O: Promotion changes title and manager
  O->>A: Updated profile values flow out
  H->>O: Termination date reached
  O->>A: Deactivate access

Stage by stage

Timing is the hidden detail

Changes do not appear in Okta the instant they happen in the source. They arrive when the next import or event runs. A promise that “access ends at once” is only as true as your import schedule. Write down the expected delay at every stage, and make sure that what HR, security, and managers expect matches what the system does.

The most sensitive moment in any ranking is when the top source stops speaking for a person.

A top-ranked source might remove a person because they left the company. It might also lose the person by mistake, for example after a bad data load. Okta cannot tell these cases apart by itself. What happens next depends on your settings, so this is the part to understand and test with the most care.

Three questions to settle in advance

Why the choice matters

If a leaver is still active in a lower-ranked source and that source can keep the profile alive, a person who has left may retain access. That is a security risk. On the other hand, if a data load mistake in the top source deactivates thousands of people at once, that is an outage. Both dangers are real, and the right balance depends on your company and its risk appetite.

Safety nets worth building

Two different questions are easy to mix up. Where does a person’s data come from, and where is their password checked?

A profile source feeds the identity card. An authentication source judges the password. These can be the same system, but often they are not. A company might take profile data from its HR system and still check passwords in Active Directory. That is perfectly normal and often the best design.

Why the difference matters

If you change the priority order, passwords do not move. If you change where passwords are checked, the profile does not move. Treating them as one thing leads to wrong fixes, such as reordering sources to solve a sign-in problem. When sign-in breaks, look at the authentication path. When a value is wrong, look at the profile sources.

The clean profile is only useful if apps receive it. Here is how the outward journey connects to the ranking.

Once Okta holds one trusted profile, it can create and update accounts in downstream apps. This outward step is called provisioning. The app mappings decide which Okta attributes go to which app fields. Because every app reads from the same ranked profile, they all see consistent values.

Why ranking helps apps

Without ranking, two apps could receive different titles for the same person, depending on when each update ran. With ranking, a change in the winning source reaches every app in the same form. This consistency matters for reports, approvals, and audits, which often rely on department or manager data from several apps at once.

Group rules as a second consumer

Group rules read profile attributes and place people in groups. App access then follows group membership. This makes profile accuracy a security topic, not merely a tidiness one. If the department flips between two values, group membership flips with it, and so does access.

The clearest reason to care about profile priority is what happens next: groups, and the access that follows them.

A group is a named list of people, such as “Finance Team”. Instead of giving an app to forty people one by one, you give it to the group. A group rule goes one step further. It reads attributes from profiles and places people into groups automatically, for example “everyone whose department equals Finance joins the Finance Team”. When the profile changes, group membership follows.

The chain of trust

Every link in this chain depends on the one before it. If the department flips between two values because two sources are fighting, the person joins and leaves groups with it. Apps are added and removed without any human decision. This is why priority is a security matter, not just a tidiness matter.

Making rules robust

When profile data is late

New hires are the delicate case. If the profile is created before the HR source has supplied the department, group rules may find a blank and place the person in no group, or in a default group. Plan for this gap. Some teams delay account creation until key attributes arrive, while others give a minimal safe set of access first and add more once HR data lands.

A good order is not guessed. It comes from a short, repeatable method.

Designing priority is mostly an exercise in listening. You gather facts about each source, you ask who truly owns each piece of data, and you rank accordingly. The technical clicking at the end is small compared with the thinking before it.

A five-step method

A worked example

In this example, the directory still owns the login name through an attribute-level choice, and Okta owns the preferred display name. The ranked list handles everything else. Notice how three kinds of rule combine into a design that is easy to describe in a few sentences.

The most common real-world setup combines an HR system, a directory, and Okta. Here is how the roles usually divide.

Many organizations still depend on Active Directory for computers, file shares, and older applications. They also run an HR system and want Okta as the front door for cloud apps. The three systems each have a natural job. HR knows the employment facts, the directory holds the technical accounts, and Okta holds the unified profile and handles sign-in and app access.

A typical division of labor

Two popular patterns

Pattern B is common during a long transition. A company may begin with the directory as the top source because that is where its data lives today. Over time, it moves HR to the top for business attributes as the quality of HR data and integration improves. This step-by-step approach lowers risk, and the priority order is the tool that makes each step controlled.

Avoiding the write-back loop

In a hybrid design, a value can travel in a circle. Okta writes a department into the directory. The directory is also a source, so it sends the same department back to Okta. If both directions are active for the same field, any delay or format difference can cause flapping. Choose one direction per attribute, and make the other mapping read-only or switched off.

Ranking is a technical setting, but keeping it healthy is a people job.

Governance means the habits and records that keep a design correct over time. A priority order is not set once and forgotten. New sources appear, old ones are retired, and business rules change. Without governance, the order slowly drifts away from reality.

Who owns what

Habits that keep the design healthy

Profile data decides who gets access to what. That makes the ranking a security control as well as a data tool.

Many access rules in Okta are built on profile attributes. A group rule may say “everyone in Finance gets the accounting app”. If someone can change their department value, they may be able to change their own access. So the question “who can write this attribute?” is also the question “who can grant access?”. Priority and ownership help answer it safely.

Security risks tied to profile sources

Protective habits

Privacy: collect less, protect more

Every attribute you import is personal information about a real person. A good privacy rule is data minimization, which means collecting only what you need. Fewer attributes mean less to protect and less to explain to a regulator. Review the list of imported fields at least once a year and drop what no app or policy uses.

You cannot manage what you cannot see. A few steady signals tell you whether your ranking is working.

Monitoring means watching the health of a system so that you learn about trouble before your users do. Logging means keeping a written diary of what the system did. For profile sources, the important question is always the same: did the right source change the right attribute at the right time?

Where to look

Metrics worth tracking

Catching flapping early

Flapping is the classic symptom of missing or weak ranking. Searching the log for the same user and attribute changing repeatedly in a short window quickly reveals it. When you find one, look for the pair of sources or mappings that are writing the same value, and remove one of them.

When auditors visit, they ask who had access, who approved it, and when it ended. Clean, well-sourced profiles make the answers easy.

Data quality means that profile values are accurate, complete, consistent, and timely. Compliance means following rules set by law, customers, or the company itself. The two are connected. Rules about access can only be shown to be followed if the data that drives access is trustworthy. Ranking your sources is one of the most direct ways to make that data trustworthy.

The four qualities of good data

Evidence auditors often ask for

A data quality routine

Instead of memorizing errors, learn a method: ask who wrote the value, then work backwards.

Almost every profile problem is a version of “this value is wrong” or “this person is missing or duplicated”. The method for both is similar. Find the exact attribute or person, list every writer, and check the order of authority. Always ask what changed recently, since most surprises follow a change.

Walkthrough 1: A value keeps changing back

Walkthrough 2: The same person appears twice

Walkthrough 3: A leaver still has access

Walkthrough 4: A new hire got the wrong apps

Start by reading the profile values that group rules use, such as department and job family. A wrong or blank value usually explains the wrong groups. Trace that value back to its source and mapping. If the source was late with the hire record, the profile may have been created from a lower-ranked source with incomplete data. Fix the timing or the order.

Every design has a price. Here is an honest scorecard for ranking profile sources.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

Sooner or later you will need to move a source up or down. This chapter shows how to do it without surprises.

Changing the order is one of the riskiest actions in a profile design, because it can change many profiles in a single run. The goal is to make the change small, visible, and reversible. Common triggers are a new HR system, a merger, a retired directory, or the discovery that the old ranking was wrong.

The safe-change recipe

Moving to a new HR system

Replacing an HR platform is a common reason to change the order. A careful approach is to run the new system alongside the old one for a while. Connect it at a lower rank first and compare what it would send. When the values match what you expect, promote it to the top and demote the old system. Retire the old source only after you have checked the people it alone described.

Here are four common situations where ranking profile sources earns its place. The companies are fictional teaching examples.

Public facts that give context

Many large organizations run several people systems at once, usually a human resources platform, a directory, and a handful of specialized tools. Okta, founded in 2009, built its business on connecting such systems to cloud applications, and its Universal Directory is designed to hold a single profile per person. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

Profile source priority is how Okta turns many competing voices into one trusted profile. It ranks the systems that feed Okta, works together with mappings and matching, and can be refined with attribute-level choices. Done well, it removes flapping values, protects access rules, and gives auditors a clear story.

A mental model to carry with you

When any profile question lands on your desk, sort it into one of four buckets. The first bucket is identity: is this the right person, and are the records linked correctly? The second bucket is authority: which source should speak for this fact? The third bucket is plumbing: is the field mapped, allowed to update, and flowing in the right direction? The fourth bucket is timing: has the next import or event actually run yet?

Most confusing situations turn out to be a mix-up between buckets. A duplicated person is an identity problem. A wrong title that keeps returning is an authority problem, often with a hidden second writer. A value that never arrives is a plumbing problem, usually an unmapped or read-only field. A leaver who still has access for a few hours may simply be a timing problem. Naming the bucket first tells you which logs to open and which team to call.

This model also helps when you explain the design to others. Managers care about authority because it is about risk. Data owners care about identity and quality because they are about accuracy. Platform teams care about plumbing and timing because they are about reliability. A good identity architect speaks to all of them, keeps the written ownership table up to date, and treats every change to a source, a mapping, or the ranking with the care it deserves.

Finally, remember the humble purpose behind all this machinery. Behind every profile is a real person who wants to start work on day one, reach the right tools, and lose nothing they need. A ranking that is clear, tested, and documented serves that person quietly, every single day.