Description of the Problem
We are experiencing a recurring identity-data issue for users whose first or last names consist of multiple tokens
In our environment:
Users authenticate to Apptio Targetprocess via Front Door SSO backed by Corporate Active Directory (AD).
We also run a daily ADM import (“WFM – ADM Import – PDOS Labor”) that updates user data in Targetprocess.
For affected users, the first and last name fields in Targetprocess are being overwritten back and forth depending on which integration last wrote the data:
After the ADM import, the user is correctly stored as:
First name: First First
Last name: Last
After the user logs in via Front Door SSO, the same account is changed to:
First name: First
Last name: First Last
This cycle repeats daily: the morning ADM import fixes the name, and the next Front Door login breaks it again.
We have reproduced the pattern with several users that have a space in their first name, so this appears to be a general parsing/formatting limitation rather than a single bad record.
Verified Source Data (AD)
In Active Directory, the data for a representative affected user is correct and clearly separated:
DisplayName: First First Last
GivenName: First First
Surname: Last
UserPrincipalName: FirstFirst.Last@…
So the root issue is not incorrect AD attributes; rather, it is how the name is parsed and mapped between Front Door and Targetprocess.
Current Behavior / Limitation in Targetprocess & Front Door
Through support, we have confirmed the following:
The background sync between Targetprocess and Front Door does not truly differentiate between first and last name in a way that supports multi-token names.
In the Authentication & Security settings, the “full name format” for Front Door users can only be configured as:
"First Last" or
"Last, First"
There is no way to distinguish between:
First First Last (multi-token first name)
First Last Last (multi-token last name)
As a result, whenever a user logs in through Front Door, the sync logic effectively splits on the space and reassigns name components in a way that is incompatible with our AD structure and with real-world names.
We attempted to mitigate this inside Targetprocess by creating an automation rule to detect and revert incorrect name changes during business hours (when most logins occur). However, due to how rule execution works, this caused an infinite loop of updates and was not a viable workaround.
Business Impact
This is not purely cosmetic. We have multiple downstream processes and scripts that rely on stable, predictable user first/last names in Apptio Targetprocess. Because the names oscillate:
Scripts and automations fail intermittently when the name format changes.
We incur manual rework and additional troubleshooting effort to reconcile which name variant is currently stored.
It creates data integrity issues when correlating users across systems that correctly store multi-token first names.
As our user base includes many individuals with spaces in their first or last names, this issue is systemic and impacts data quality across our environment.
Requested Enhancement
We request an enhancement to the Front Door ↔ Targetprocess identity synchronization and/or Authentication & Security configuration to properly support multi-token first and last names. Specifically, we are looking for one or more of the following capabilities:
Configurable Field Mapping Using AD Attributes
Allow mapping Targetprocess FirstName and LastName directly from specific AD attributes (e.g., GivenName, Surname) rather than relying on a simple “full name” string and splitting logic.
Ensure that multi-token values in GivenName and Surname are preserved as-is and not re-parsed or re-split by Front Door.
Enhanced Full Name Parsing Options
Extend the “Full name format” options beyond just "First Last" and "Last, First" to support multi-token names such as:
First First Last
First Last Last
Provide explicit configuration to indicate which side (first or last name) may legitimately contain spaces, and ensure those tokens are not automatically moved across the boundary.
Preserve Existing Targetprocess Name When Ambiguous
When the sync cannot confidently parse the full name into first and last components, provide an option to:
Not overwrite existing Targetprocess first/last name values; or
Only update name fields when they are empty or known to be incorrect, instead of always forcing the split result from Front Door.
Administrative Override / Protection for Specific Users
Optionally, allow administrators to “lock” first/last name values for specific users in Targetprocess so that SSO sync does not override them, particularly when AD is already the source of truth and the current Targetprocess values are correct.
Why This Needs Platform Support (and Cannot Be Solved Locally)
AD already stores the name correctly and distinctly (GivenName vs. Surname).
The current Front Door + Targetprocess configuration model does not allow a reliable way to:
Preserve multi-token first names, or
Respect AD attributes as the authoritative first/last name split.
Attempts to fix it purely through imports or automations in Targetprocess lead to conflicts with the SSO sync and, in our case, infinite update loops.
Given these constraints, we believe this requires a platform-level enhancement to the name handling logic in Front Door / Targetprocess.
Summary
We are asking IBM to:
Enhance the Front Door ↔ Targetprocess identity sync so that multi-token first/last names are correctly supported, preferably via:
Direct AD attribute-based mapping (e.g., GivenName → FirstName, Surname → LastName), and/or
More flexible and explicit full-name parsing and overwrite rules.
Provide a configuration path that allows customers to avoid the constant “tug-of-war” on user names between imports and SSO logins, which is currently causing real failures in downstream automation.
We would be happy to provide concrete examples, logs, and configuration screenshots to help validate and design the enhancement.
