We sometimes get the question, if it’s possible to include the organization tree into Connections Profiles. As you know, since Connections Profiles is user centric, and it includes a hierachy, but the hierarchy is based on people, there is no real separate hierarchy that depicts the organization tree.

Now this article describes how you could include your organization tree in Connections Profiles, as a profile type.


The idea is to use a custom profile-type for departments, or organizations.
This means we would need to import the departments from somewhere, and store them in Connections Profiles with the “default” profiles.

I’ll take some shortcuts here, since this is merely a demonstration of the principle. So I’ll store the departments/organizations in LDAP , in a way that I can easily pick them up using the default TDI assemblylines that come with Connections. I do not make any programmatic changes to the TDI assemblylines , although in reality, that’s what you’ll want to do if you want to deploy this solution in a production environment.

Note that there is no (out of the box) way to edit the deparments using “Edit my Profile” - a Department cannot log in to Connections. So all the information you want to store in the Organization’s/Department’s profile must be in the source where TDI syncs from, in this case LDAP.

End result

So in the end, I would have an actual profile for my departments (organization’s tree), which give me a lot of possibilities.
I could add a richtext field to them , to show more data about them, although I did not do that here.
I could also tag or let the organizations be tagged.
I can link users’ profiles to his organization’s profile,…

Notice the Report-to-Chain widget, which shows the hierarchy for the organization…

Image:How to show your Organization tree structure as separate Profile types in Connections Profiles (part 1)

And what it was all about in the first place, I can show the organization tree, using the out of the box Reporting Structure feature in Connections…

Image:How to show your Organization tree structure as separate Profile types in Connections Profiles (part 1)

Because the organizations are stored as profiles, the standard profile search applies. So if I do a search on keyword, “marketing”, I get the marketing departments together with the actual people. Visually, it’s pretty easy to distinguish them.

Image:How to show your Organization tree structure as separate Profile types in Connections Profiles (part 1)

Also in the Full text search over Connections, the results will appear :

Image:How to show your Organization tree structure as separate Profile types in Connections Profiles (part 1)

OK, now on to how to actually do this ….


Departments stored in LDAP

To store the departments in LDAP, I created an Organizational Unit (ou=Organization), and created the Departments with following attributes:

  • used 2 objectclasses (organizationUnit and inetOrgPerson) - to have all the attributes available to me . To have matching attribute names for the mapping in TDI, this was the easiest solution (although I would not recommend it in a production environment).
  • added the fields I intend to use in the Departments Profiles later on:
  • sn : the lastname is required by Connections, so it needs to be added. It’s also a required field in the inetOrgPerson schema anyway.
  • telexNumber : will be used to store the profile-type
  • departmentNumber : contains the department number. Is not actually used, but will be synced to Profiles.
  • manager : contains the higher level organization, so a tree can be constructed.
  • searchGuide : a field that could contain a link to the profile of the Manager of the Department. The logic here is more applicable the other way around : the user’s profiles could contain links to the departments they belong to a similar way.

dn: cn=Corporate communications - 2C2,ou=Organization,dcÞMOS,dc=IBM,dc=COM
objectClass: person
objectClass: top**
objectClass: inetOrgPerson**
objectClass: organizationalPerson**
objectClass: organizationalUnit**
cn: Corporate communications - 2C2
ou: 2C2
sn: Corporate Communications**
departmentNumber: 2C2**
description: Corporate Communications
mail: organization.2C2@demos.connectionsww.ibm.com**
manager: cn=Corporate Communications - 2C1,ou=Organization,DCÞMOS,DC=IBM,DC=COM**
physicalDeliveryOfficeName: Office at the 3rd floor searchGuide: http://connectionsww.demos.ibm.com/profiles/html/profileView.do?email=nolmos@demos.ibm.com&lang=en secretary: cn=Vivian Hanley,DCÞMOS,DC=IBM,DC=COM telexNumber: organization

My full LDIF file is here : complete_organizations.ldif

TDI sync

TDI mapping

Since we now have the Organizations in LDAP, we just need to make some changes to the mappings and to the ldap search filter :



I add a filter for the OrganizationalUnits (which do not have a uid).




Change the following default mappings.


The only real important field here is the profileType mapping, to `telexnumber, a field that we abuse in the LDAP. Since normal users do not have a telexnumber, they will be mapped to the “default” type. In practice, you would likely set the profileType in your assemblyline by scripting, so you don’t have to create a specific mapping for it and you don’t have to store it.

Now would be a good time to run a full sync, so the Profiles Database is updated.



Now to make it easier to identify these new profiles as being “organizations” instead of real user profiles, it’s a good idea to give them a profile picture.

I’m using the out of the box Assemblyline that comes with Connections, and that you can run with the script load_photos_from_files.sh (in the TDISOL directory).

It depends on a file collect_photos.in (in the TDISOL directory) to contain a list of photo locations and then the uid of the user to assign it to.
I’ve put the photo (org.image.jpg) in the directory /opt/IBM/TDI/TDISOL/dump_photos/ and have following lines in the file

uid:Office of the CEO  
uid:corporate communications - 2C1  
(continues ...)  

Run the script


This concludes the TDI configuration.

Part 2 : How to show your organization tree structure as separate profile types in Connections Profiles (part 2)