It is almost always a bad idea to create extra objects types for the same basic “thing”. An object type should encompass all the possible states an identity can transition to. A person can never become a group, but they can definitely be staff, contractor or student (sometimes all at the same time) so a single “person” object type should be used for all people.
This best practice applies to both the Metaverse and the Portal. It may be tempting to try and extend the number of RCDC forms available in the Portal by declaring new object types for similar identities – but it is a mistake. Some of the pitfalls:
- You will run into problems where multiple roles lead to multiple identities and accounts,
- You will find it very difficult to transition an identity to a different object type – in fact they will have to be re-imported into the IAM system, and re-joined to existing accounts, and you will have to do a lot of this by hand,
- You will do a lot of work re-creating schema definitions and Sync Rules and Portal policy objects, and then having to maintain them, and
- You’ll end up losing benefits from task automation by working in too much fundamental complexity and inflexibility in dealing with moves and changes.
It really is better to stick to the one object type and make do with roles, attribute values and flags to differentiate between your categories.
Do you have any advice regarding using the out of the box object types? I have been using the person & group type but find it a bit unwieldy and am thinking it would be cleaner to create a new object and use that.
If you’re using the Portal there is a lot of OOB stuff that is already configured for the person and group object types, so you’ll have a lot of work re-creating all that yourself. I always use the OOB person and group types in the Portal, and for clarity I match them to same-named types in the Metaverse. There’s no problem deleting Metaverse attributes and adding new ones. You can also delete Portal bindings that aren’t directly related to functionality (such as ResourceId, ResourceType, DisplayName, AccountName, ObjectSid, Domain).