I am working on a project where we have federated repositories i.e., LDAP and BPM (internal groups and users). The project is meant for a large enterprise, the enterprise itself has many groups in LDAP (departments and sub departments) and each employee has his/her hierarchy (managers and their managers) defined in LDAP.

Now the question arises, if I will create new groups in LDAP (pertaining to the maker/checker and other approvals), of course they will appear in IBM BPM and they will start appearing in Microsoft Outlook etc. as well, but will it be a good solution because many times the groups which are created for BPM related activities/tasks are not too much relevant to the enterprise hierarchy and structure and those are also not relevant to other applications.

Your invaluable input is highly appreciated.

Hi Muhammad,

the product supports both approaches, because are valid use cases.

• Many companies have LDAP with existing groups that represent organizational structures. If these exist, it's smart to use them.
• Many companies have established procedures around requesting access in one tool, getting approval for this access request and then be added to an LDAP group that manages this access. All properly audit logged. If such processes are established, use them for the "role based access control". That is, if you need to expose the start of a process type to a corporate defined set of users, these "managed LDAP groups" are a good candidate.
• If there are many small use cases of fine grained access control on task level that requires you to have hundreds of groups, which would pollute LDAP, internal (BPM managed) groups are a good choice.

You may even have a combination of both:

There may be an existing LDAP group with all engineers and you want to grant them permission to start your process. In addition, there is a group of 5 interns that also need to work on some of the tasks. You can create a BPM managed group that includes the LDAP group + 5 interns. This does not make the 5 interns engineers on corporate level, which may have much wider consequences. It only grants access to the narrow use case you defined and you can let some business users manage membership in this internal group - bypassing all the challenges and delay which may be associated with maintaining LDAP groups.