What is the difference between a standard login field and a linked custom field?

What each field actually stores

A standard login field is a value-holding form field. It can capture whatever the page designer intends, such as a PIN, a checkbox state, a note, or another custom input. The field’s value lives in that field and is saved as its own data rather than being tied to a specific account secret.

A linked custom field is different because it does not store an independent value. It acts as a mapping layer that points a nonstandard page field to the item’s saved username or password, so autofill can place the right secret into sites that label fields in unusual ways.

Why the distinction matters for autofill behaviour

The practical difference is whether the field is a separate piece of item data or a pointer to existing credential data. Standard fields are useful when you want the item to remember an extra value that is not part of the login itself. Linked fields are useful when the site’s form structure is awkward, but the thing being filled is still the username or password.

This distinction is what lets a password manager adapt to inconsistent login forms without duplicating sensitive data. A linked custom field preserves a single source of truth for the credential, while still allowing the page to receive the value through a different field name or layout.

That is also why linked fields are usually treated as part of the login configuration rather than as another stored secret. The value comes from the item’s existing username or password, not from a second, separately managed field entry.

When to use one versus the other

Use a standard login field when the page asks for a distinct piece of information that should be saved independently of the username or password. Use a linked custom field when the page is really asking for the same username or password, but the form uses a nonstandard label, placement, or input name that prevents simple autofill matching.

In practice, the decision turns on whether the value should be reusable on its own. If yes, it belongs in a standard field. If no, and it is only there to help autofill reach the existing login secret, it should be linked instead of stored twice.

Practitioner Guidance

What to verify: Confirm whether the target field is meant to hold a distinct application value or merely a renamed username or password field. If the page can change without warning, linked fields are more brittle than standard fields because they depend on form structure staying recognizable.

Common mistake: Do not create a new stored value just because a site uses unusual field names. That can fragment the login record, make updates harder, and increase the chance that the wrong value is autofilled into the wrong place.

Practitioner takeaway: Treat linked custom fields as form-matching metadata, not as separate secrets. If the value should stand alone, store it normally; if it only exists to direct autofill to the saved username or password, link it instead.

Related resources from NHI Mgmt Group

• What is the difference between direct access and effective access in Active Directory?
• What is the difference between managing human identities and non-human identities?
• What is the difference between custom workflow exclusions and standard security automation?
• What is the difference between a converged identity credential and a standard password based login approach?