A lot of intranet projects aim to deliver functionality related to personalisation or customisation.

This may involve tailoring information based on staff role, delivering news relevant for specific offices, or limiting access to information based on seniority.

Any of these capabilities requires the system to know who staff are, the business unit they belong to, and where they sit in the real world.

Unfortunately, too many of these projects run aground before they start because a key piece of IT infrastructure has not been correctly put in place.

Active Directory

Sitting invisibly behind the scenes in organisations is the ‘authentication’ platform run by IT. In simple terms, this contains the usernames and passwords staff use when they log on to their PCs each morning.

In most cases, these details are now stored Active Directory (Microsoft’s version of LDAP, if you were wondering!).

This has the ability to store much more than just names and passwords. If configured to do so, it can contain all the information that is in the internal phone directory or staff directory, including job titles, business unit names, locations and more.

The most obvious benefit to come from putting in place these new standards is the progressive move towards ‘single sign-on’, allowing one username and password to be used across a wide range of corporate systems.

Crucially for intranet projects, Active Directory is also the source of the information needed to drive personalisation and customisation.

Instead of the intranet building its own database of staff information, staff details are drawn out of this directory service platform.

And this is where the problems become apparent, because these platforms are often not configured in a way that works for intranet projects.

Technology narrowly implemented

Active Directory was originally deployed by IT to manage just usernames and passwords, as replacements for legacy platforms. The focus of these projects was on managing the technology transition, not adding extra functionality.

While usage has been somewhat expanded since, improvements to directory services have been driven solely by IT considerations. There has been little opportunity for business or information management areas to get involved in defining platform needs.

This means that even when details such as business unit are implemented, they are often captured in ways that don’t match how they are used in the business.

Capturing the right details

Fundamentally, Active Directory needs to contain at least the following information to support personalisation and customisation:

• job title
• job role
• business unit
• office location
• direct manager

These details also need to be kept up to date, through direct integration with HR systems, as well as via self-service updates in the staff directory.

Start by talking with IT

While very technical, and far from sexy, underlying directory services are vital for the next generation of intranet and portal projects.

The starting point for intranet teams must be to engage in discussions with IT about these platforms, to gain a clear understanding of what is in place, and how it works.

The necessary improvements to these underlying platforms must start well in advance of the intranet work, and managed as a joint IT/business project. Only then will true personalisation become possible.