Advantage: For many users there is no need to create a user map anymore.
we would like to have the Octane connector with another user representation: "octane_full_name". Currently there are email, name and full_name. The latter (full_name) is a formed value of first and last name (we've checked it). Say MF Connect makes the Full_name currently so: First Name + " " + Last Name. Unfortunately, in our AD, the combination of first and last name are not the same as the display name. The display name contains special characters, whereas the first name and last name do not.
We map the DisplayName field in Octane with the Full Name field (LDAP Server Settings). However, this field is not provided in MF Connect. If the field existed, the user in Jira (also DisplayName) would exactly match the one in Octane. User mapping would no longer be necessary.
We have dozens of Data Sources and over thousands of users. The user mapping is not perfect, even with .bat-File automation.
Several approaches for minimizing the need for MF Connect User Maps are currently under consideration - currently (subject to change at any time) as "SHOULD HAVE" for the next release of MF Connect and "MUST HAVE" for the release(s) after that).
The scenario here is one of them - but the not among the TOP items of the list of user mapping improvements (as it requires changes in the product Octane, as well - and it is not generally applicable to all or even most customer scenarios).
Common to all potential user mapping improvements is the goal to reduce the need for User Maps that need to be maintained.