SCIM server doc updates

site/docs/v1/tech/core-concepts/scim.adoc

@@ -195,7 +195,7 @@ With SCIM, users are provisioned. They are not registered for applications withi
 Options to automatically add a registration to a new user include:
 
 * Listen for the link:/docs/v1/tech/events-webhooks/events/user-create-complete[user.create.complete] webhook and add the registration using an API call on the receiver.
-* Make an API call from the link:/docs/v1/tech/lambdas/scim-user-response-converter[user response complete lambda]. Ensure this idempotent as the lambda will be called any time the user is updated as well.
+* Make an API call registering the user to an application from the link:/docs/v1/tech/lambdas/scim-user-response-converter[SCIM User Response Converter lambda] which is called after the user is created. Ensure this idempotent as the lambda will be called any time the user is updated as well.
 * If you enable self service registration for your application, and the user logs in to the application, they will be automatically registered for the application. link:/docs/v1/tech/core-concepts/registrations#registrations-and-self-service-registration[Learn more].
 
 == SCIM Client Authentication

site/docs/v1/tech/shared/_scim-limits.adoc

@@ -1,20 +1,16 @@
-The current SCIM implementation does not support:
-
-* Bulk operations
-
-Bulk API operations are available via link:/docs/v1/tech/apis/[FusionAuth APIs], but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a https://github.com/fusionauth/fusionauth-issues/issues[GitHub issue] explaining your use case.
+The current SCIM implementation does not support bulk operations using SCIM. Bulk operations on users, such as addition and deletion, are available via link:/docs/v1/tech/apis/[FusionAuth APIs], but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a https://github.com/fusionauth/fusionauth-issues/issues[GitHub issue] explaining your use case.
 
 The list operation is limited to 10,000 users if you are using the Elasticsearch search engine. This https://github.com/FusionAuth/fusionauth-issues/issues/494[GitHub issue] discusses this limitation.
 
-You cannot create a FusionAuth Registration for a user provisioned with SCIM. If you need to register the user for one or more Applications, you have a few options. You may:
-
-* use the link:/docs/v1/tech/lambdas/scim-user-request-converter[SCIM User Request Converter Lambda].
-* use the link:/docs/v1/tech/events-webhooks/events/user-create-complete[`user.create.complete` webhook].
+You cannot create a FusionAuth Registration for a user provisioned with SCIM directly during the provisioning process. See link:/docs/v1/tech/core-concepts/scim#adding-registrations[Adding Registrations] for workarounds.
 
-Either works. The correct choice depends on if you want to do the processing within FusionAuth using a lambda or using an external server.
+While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM client per tenant. While you can have multiple SCIM clients configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need multiple SCIM clients provisioning users into a single tenant, ensure you handle conflicts.
 
-While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant.
+Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant.
 
-While you can have multiple SCIM servers per configured within one tenant, at the end of the day you only have one user data store per tenant.
+Issues with this approach include:
 
-Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts.
+* The user and group lambdas would have to include logic to differentiate between a user from Okta and a user from Azure AD and handle the fields differently. The incoming SCIM request does not include information about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from.
+* User collisions are not handled by FusionAuth. If the Okta SCIM client created an account for a user with the email address `richard@example.com` in the tenant, then later the Azure AD SCIM client tried to create an account for a user with the email address `richard@example.com`, the second account creation would fail. One workaround would be for the lambda to resolve the collision, for example by adding a suffix or prefix to make the email address unique. 
+* Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD SCIM client and vice versa.
+* The bearer access token used to authenticate each SCIM client can be different, but they must have the same lifetime, since that is configured at the Entity Type level. You couldn't have Okta's credentials be valid for a year but Azure AD's credentials be valid for six months.