As a short technical info…
Documentum has groups, roles (actually groups with “tagged” as roles) and users.
Groups can be defined inside Documentum itself or taken from an LDAP source. Mixed.
Roles are not much different, you can use roles and groups interchangeably for the most time.
Users can be defined inside Documentum, taken from LDAP or mapped to OS users.
FileNet knows about groups, roles and users.
Groups and users are always from the LDAP (ActiveDirectory). Only. Replicated from.
Roles are strictly tied to the features exposed in the standard UI (Workplace).
Both Documentum and FileNet have permission sets with some templating features.
And now ask yourself how many times did you need to “group” together users in your CM solution. Aiming to enable one user access to some data just by adding him to the proper group.
Quite frequently, didn’t you?
In FileNet this means the group must exist in LDAP and users must be in that group in LDAP. Not in the DMS system. Oops! Here comes PITA! You need to call IT to create the group (usually manually) and add users in it. You can’t do it directly through a DMS API or admin interface.
As I understand it, somewhere in the design time for FileNet, somebody took the decision “we’ll take all our users and groups from the LDAP”. After all.. LDAP is where users and groups should be, isn’t it? By this decision they actually limited the flexibility of the platform for solutions and imposed a great deal of stress on the real world solution builders.
In the real world you don’t have all your business groups in LDAP. At least not in the majority of organizations. Also, the LDAP structure is generally managed by IT not by the business. Sure, we have “identity solutions” on the market but this is still a long way from having it implemented and properly used.
Sorry FileNet, but this round goes to Documentum.