Generate sign-in names with naming rules

Some systems create a person's address or username when Owlie creates their account, such as a user principal name in Microsoft Entra ID or Active Directory. A naming rule generates that value for each new account. Owlie picks the first candidate that no other account it manages holds, and moves to the next candidate when the target system reports that the value is taken, for example by a former employee's disabled account.

Choose a naming rule

1. Open the resource and select its Provisioning tab.
2. Under Baseline attributes, set the attribute that holds the sign-in name, such as userPrincipalName, to Username Generator. A profile can have one generated attribute.
3. Select the formula box to open Unique Value Generator.
4. Under Naming rule, choose a rule, then either enter an Account domain or, for a connector-fulfilled resource, an Install-config field naming a field from the connector's own configuration (whichever you fill in wins), and select Use this rule.
5. Select Save Configuration, then save the resource.

Naming rule	Builds the value from	Example
Email local part (default)	The part of the identity's email before the @	jsmith@acme.com
first.last	First name, a dot, then last name	jane.smith@acme.com
flast	First initial followed by the last name	jsmith@acme.com

The examples are for Jane Smith, whose email is jsmith@example.org, with the Account domain acme.com. The name rules fold accents and drop punctuation, so "José Núñez-O'Brien" becomes jose.nunezobrien. When a candidate is taken, the next one adds a number: jane.smith2@acme.com, then jane.smith3@acme.com.

Without an Account domain, Email local part keeps the domain of the identity's own email, and the name rules produce a bare username such as jane.smith. Choosing a rule writes out its steps in the editor, and you can still edit them afterward. Max Attempts limits how many candidates Owlie tries: 5 for Email local part without a domain, and 10 otherwise.

The built-in Microsoft Entra ID, Microsoft Teams, OneDrive and Active Directory templates already generate the user principal name with Email local part.

Reading the domain from the connector's own configuration

Typing an Account domain freezes that value into the generator's steps: changing the connector's own configuration afterward doesn't move it. For a connector-fulfilled resource, enter an Install-config field instead (for example domain) and Owlie reads the value from the connector's own configuration each time it generates a candidate, so the account domain always tracks the install. This works for any block that reads a field, not only the domain: open a step's field block and choose Config field… to read any of the connector's own configuration fields the same way.

Try the sign-in email first

Turning on First try the sign-in email adds one attempt ahead of the naming rule: Owlie tries the identity's own sign-in email, unchanged, before the rule's first candidate. It's only tried when the identity has a verified sign-in email — a pending or unverified one, or none at all, skips straight to the naming rule, so this option never blocks an account from being created. When a sign-in email is available, the account gets it verbatim, matching how the person already signs in to Owlie; the naming rule still runs afterward, with the same candidates and rotation as if the option were off.

Limiting how long the generated value can be

Some systems cap the field a naming rule fills — Active Directory's logon name (sAMAccountName) can't be longer than 20 characters. Set Max length on the naming rule (or add a Truncate to... modifier to a block by hand) to cap it. The cut is rotation-aware: on a later attempt, Owlie reserves whatever width that attempt's own number actually takes (2 is one character, but 10 is two) before shortening the identity-derived part, so two long, otherwise identical names never collide just because their numbered suffixes happened to land at different widths. A domain a naming rule adds (an Account domain or an install-config field) is never counted against the limit or cut — it isn't part of what a target like sAMAccountName holds.

Active Directory's built-in template sets Max length to 20 on its user principal name, so the value sAMAccountName and cn read (see below) always fits.

Build other attributes from the generated value

Other baseline attributes can use the generated value as generated in their expressions, so related fields always agree with it. For example, a mail nickname can be the part before the @:

split(generated, '@')[0]

OXL has no method calls, so generated.split('@') doesn't work. Active Directory's default profile already sets sAMAccountName and cn to split(generated, '@')[0] and mail to generated this way. When Owlie moves to the next candidate or renames the account, every attribute built from generated changes with it.

An attribute that reads generated can't have Sync turned on, and Owlie refuses to save one that does. It updates whenever the account is provisioned or renamed. Hooks can't read generated; they can read the account's stored value instead.

For a connector-fulfilled resource, a baseline expression can also read the connector's own configuration as config, the same install-config values the naming rule's field block can read — for example config.domain for an email domain. Owlie never exposes a secret or password field of the connector's configuration this way.

When a candidate is taken

When Owlie creates an account and the target system reports that the value already exists, Owlie tries the next candidate and creates the account again. If every candidate is taken, the operation fails instead of trying forever, and the next provision starts again from the first available candidate. Only account creation moves to the next candidate: a rename or an update that the target refuses fails.

Existing accounts keep their name

Once an account exists, its generated value never changes on its own. It stays the same when the person's name or email changes, when a sync runs, and when you edit the naming rule. A new rule applies only to accounts Owlie hasn't created yet.

Two changes to the profile do affect existing accounts:

• Replacing the generator with a plain mapping on the same attribute renames every existing account the next time it is provisioned. Owlie warns you and asks you to confirm when the resource has live accounts.
• Moving the generator to a different attribute makes each existing account's next provision fail until you rename that account.

Rename an account

To change a generated name, such as after a legal name change or a typo, open the identity, select the Resources tab and select Rename sign-in name on the account. The action appears only when the resource generates a sign-in name, and you need the provisioning.modify permission.

New sign-in name starts with the naming rule's first candidate for the person. Edit it if needed, then select Rename. The new value must not be empty, must fit the target field, and must not belong to another account Owlie manages on the same resource.

Owlie changes the sign-in name and every attribute built from it in one operation, and nothing else on the account. A rename grants nothing and records no access, so it never keeps an account alive after the policy or request behind it ends.

People hired before their work address exists

HR often creates a person before their work mailbox exists. Owlie's built-in HR connectors, such as Workday and BambooHR, map only a work address to Primary email. BambooHR sends a personal address to Secondary email instead. A pre-hire therefore has no email yet, Email local part has nothing to build from, and the provision fails with an error that names the missing value.

For a system that issues the work address, such as Microsoft Entra ID, use first.last or flast with an Account domain. Owlie builds the address from the person's name, and once a sync of that system reads the new account, the address can become the person's email.