The field "object field to match" needs to point to the field in the LINKED object you want to match. I don't think "Supervisor" is the field on the "Employee" object you need.
So if your Person1's manager is Person2 you want to link to Person2's field containing their name. The field containing the name is of course DisplayName. Link to that.
Also I don't load the Manager field and I definitely don't load it with "use default" set and then not set to anything, because I think I'm right in saying that'll wipe it clean, invalidating the bother you just went to to link it. Again I'm on a newer version than you, but it seems to look the same so it might help you.
OK, first off: the "DisplayName" field we're linking to is the one in ISM (HEAT). Not AD. I don't know if you're importing that one, but HEAT's Displayname looks like [givenname+" "+sn] for me, and I've the same field map for first and lastname you do. My AD naming ALSO matches the DsplayName format ISM/HEAT uses to format names. Yours does not, judging by the names I'm seeing in your screencaps.
So, you might consider taking that short name and putting it in a field you're not using. The Network Username field for instance. And then link to that in the ManageLink (Link) field.
If I were to use our short-codes (which I store in the samaccountname field, because that is what they are) instead of full names in AD, it would look like this.
The end objective is this: the result of $(ParseDN(Manager, 0)) needs to look identical to whatever you put in the field it's looking at. DisplayName is one likely field but it's not mandatory to use that one.
as Aart pointed out: $(ParseDN(Manager, 0) will return the first part of the Manager field in AD, which should be 'iye'.
Probably that's the manager's LoginID.
Hrm...regardless of field mappings, can we agree that my ParseDN should return something? I'm not getting anything returned into that field - at all.
In the case of bart, the AD attributes are:
In the case of jye, the AD attributes are:
... it definitely should; and its working for me.
There's one little thing: I use 'manager' without capitals, like '$(ParseDN(manager, 0)'; not sure, if its case-sensitive here; can you give it a try?
Mine is 'manager'...but I've tried both.
I'm confused on the statement 'I don't know if you're importing that one, but HEAT's Displayname looks like... ' I'm importing AD attributes (by way of LDAP) and mapping those to ISM names. So I'm not importing ISM DisplayName.
So my understanding of the Contact Relationships is this:
I'm using the ParseDN function to grab the manager AD attribute of the user being imported, taking the first k=v value (cn=name, taking the 'name' value), and mapping that into ISM Display Name. So something should show up in the Manager field, yet I get nothing.
I'm confused on 'Display Name' in the CR mapping. I would think the value to be mapped would be a field called 'Manager' on the Employee record. Looking at the Employee business object, there isn't a manager field, rather a ManagerLink field. The ManagerLink field is a relationship EmployeeAssociatedProfileEmployee. But from there I'm lost.
You are NOT importing AD's displayname in your screenshot. So the field DisplayName you're looking at is what ISM makes by sticking firstname in front of lastname with a space in between them.
This is why you're getting confused I think.
The other thing you're sonfused about is what object you are mapping to.
The managerLink field is a link to another Employee object. The field you say to link to is the field in which it looks for identical data to the AD field you're naming.
- the result of $(ParseDN(Manager, 0)) is going to be "jye" in your example.
- there must be an ISM field in the Employee object into which that "jye" is put; there is none in your example.
- you must map to that field. You're not doing that in your example.
DisplayName in your example doesn't contain jye because you're not mapping anything into DisplayName (so ISM autogenerates it).
The end objective is this: the result of $(ParseDN(Manager, 0)) needs to look identical to whatever you put in the field it's looking at.
Having understood this, go back to my previous post about mapping that data into another ISM field and then linking to that.
One caveat: again you appear to be under the impression you're looking for data in AD fields (displayname in this case). You're not. ALL querying is done to ISM fields. The field mapping copies precisely the fields you specify from AD over to ISM and then AD ceases to be a consideration. Anything you have in AD that you do not explicitly map to a field in ISM is in no way visible to ISM. You *must* map all the fields you want to use. You're not mapping displayname here, so you can't use it. The fact that a field by the same name exists in ISM does not make that field magically contain AD's information. Worse, that particular field is auto populated by ISM, causing you potentially more grief.
Thanks for you help and understanding as I'm new to SM. I have it working but not entirely sure I understand it yet.
I have the following working.
The manager relationship is built using the value returned from ParseDN(manager, 0) which is 'exactly' matched to an ITSM field, NetworkUserName that contains the same value. In the case of my AD user account:
- ParseDN(manager, 0) returns jye (from the AD manager attribute manager=CN=jye,OU=users,OU=lab,DC=msrslab,DC=us)
- ManagerLink(Link) searches/finds an employee record having a Network Username = jye (from the importing of displayname to Network Username)
- ManagerLink(Link) is created by matching ParseDN(manager, 0) with a NetworkUserName
I think I got it!!