3

My current client has 6 Prod Org, now they want to track license detail of all the org and their usage. Like they want to track which user has which Org access, license information,profile and permission set.

Currently we have created two custom object which has master-detail relationship in one org, where Master object will store user information and detail object will store org information like Org name, profile etc.

Currently we are manually uploading data in all these object, but in future we want to automatically upload all these details, like whenever a new user is created or deactivate in any Org it should automatically update in my custom object.

How can I achieve this? Is there any alternative approach of doing this apart from creating custom object?

2

Custom objects are your only real viable option here. Basically you need a "hub" org to track all the other orgs and have them talk to one where you're tracking them all in one place. You could add a lookup to contact and add all your users as contacts under your company's account. This way a contact can be created when they are hired and as they move through hire process you can add what orgs they need. If your levels of access are on point then it's easy to add picklists or text boxes for what access they need, then it's as easy as doing a api call to the other org with the user details from the contact and custom object and creating a new user.

At my last company we had something very similar but it took a long time to implement. I would recommend:

  • Create objects to track the access - do manual updates
  • Introduce functionality to update the user accounts with login information so you can run reports to see who needs to be deactivated. - still manual updated
  • Now that you're able to talk between the orgs introduce deactivations automatically from the hub org. These are easier because you're just updating the Active checkbox.
  • Now that you can automatically deactivate, probably in nightly batches you can start to automatically create users. This is harder because you have to have their profile, role, permission set, timezone, username predefined and ready to be passed through a api call. It also means you need to have all your profiles consistently named so you can do some name == name when looking for profile ids, or else it gets real hard.

This is doable and when you're going multi-org it seems essential because the alternative is one users activating deactivating people all day and that time spent will certain scale up as you get more users/orgs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.