We are currently working on an interface between ISC and Dynamics 365 CRM via the OOTB connector, and one major limitation is that creation is not supported on this connector.
There is a strong dependency on EntraID and license synchronization, which to date has been handled via EntraID groups. In our context, the synchronization delay between the two components is not controlled (announced between 15 minutes and 2 hours).
Actuellement notre scénario priviligié porte sur l’utilisation de rôles automatiques qui permettront de positionner les permissions fines dans Dynamics, les conditions de ces rôles porteront notamment sur la présence dans le groupe de licence ainsi que d’avoir un compte Dynamics.
Currently, our preferred scenario focuses on the use of automatic roles, which will allow us to assign fine-grained permissions in Dynamics. The conditions for these roles will notably include membership in the license group as well as having a Dynamics account.
In your context, how does work your implementation with Dynamics 365 CRM ?
We had a similar use case and we did this using a Web Service Connector which was handling the Creation/Disable of the user where as the other operation were handled by OOTB connector.
I have few questions regarding your implementation:
How does account creation work with the Web Service connector and EntraID synchronization? We tried creating accounts via API, but the EntraID sync (after assigning a license) renamed our account and created a new one linked to EntraID. azureActivedirectoryObjectId seems to be en read mode during account creation through API.
Could you provide more information on what the user is requesting in SailPoint? I don’t clearly see how it works to create account with one connector and add rights with another one.
We request Azure Group from Service Now Catalogue. We have used the new feature of the catalogue where we have questions asked about the manager,city and other details in Dynamics. Once the form is filled it is submitted and after approval we are trigger a workflow of Provisioning Completed. In the workflow we are first checking whether the user is created in Dynamics. We wait till that time and once we get that response as success we then try to update the user. This has been tested and working perfectly fine at our side.
The user is requested Entra Groups…Once they request the above process follows.
We had the exact requirement in our project too. We initially did a POC with Webservice connector (to handle the account creation) but we ended up using only the OOTB connector.
We implemented this in IdentityIQ, I do not see a difference in the connector for ISC, hope this helps.
This is how we did it:
Defined our business roles with securityroles of CRM. These business roles also inherit the license and SSO(Access) group of CRM.
When user places a request for the respective security role of CRM in SailPoint, SailPoint grants access to license and SSO groups (as part of inheritance), however it attempts to provision the CRM account and fails . We added a custom user-friendly error message in Before Provisioning rule and threw an exception to avoid the technical error on the request.
CRM account gets created as part of the sychronization between Entra and CRM (takes over 45 minutes) after the group provision
As the business role is already assigned to the user, SailPoint attempts to reprovision the entitlements that are not detected on the identity in the next cycle and user gets the needed access.
We communicated to the business on the timelines for fulfilment of the new account due to the synch delay and dependencies. Conclusion is, if the delay of creation due to synch can be communicated to the business, using OOTB connector is sufficient for implementation too.
On the other hand, with a Webservice connector, the creation can be completely automated too
We will deploy a similar solution, except that we will use fictitious Active Directory groups as triggers to add the Dynamics license.
Once the account is synchronized through the OOTB connector and detected in this fictitious group, we will provision the appropriate permissions on the Dynamics account.
We will also review the aggregation schedule to run it every 4 hours, which will ensure effective access within a maximum of 5 hours.
Understood, sounds good. The only reason we didn’t want to proceed with Webservice connector is additional maintenance. We have around 30+ CRM instances to be integrated, using OOTB connector helps us staying on the low-code approach and gets support of the connector updates in future.
We also had Dynamics F&O integrated, which earlier didn’t support creation as operation and that is supported now. Similarly, we didn’t want to miss out any connector updates to CRM, hence we did stick with the delay in the fulfilment as the approach.