diff --git a/src/api-reference/user-provisioning/v4.user-provisioning.md b/src/api-reference/user-provisioning/v4.user-provisioning.md index 63478afcc..f80ec0a96 100644 --- a/src/api-reference/user-provisioning/v4.user-provisioning.md +++ b/src/api-reference/user-provisioning/v4.user-provisioning.md @@ -64,11 +64,10 @@ The following guidelines outline the best practices for working with the SAP Con ### Key Recommendations * Use the `/Bulk/` endpoint for batch operations (up to 100 operations per request) and `/Users/` for single-user operations. -* Use `PATCH` operations instead of `PUT` for regular user updates to minimize error rates. +* Use `PATCH` operations instead of `PUT` for regular user updates to minimize data loss risk. * Track provision completion using the `provisionId` returned in the response, either via polling (with exponential backoff) or webhook notifications. * Pre-validate data before submission — most failures are caused by data validation issues. * When identity extensions fail, retry the entire operation after fixing the issue. When spend/travel extensions fail, retry only those extensions via a subsequent `PATCH` request. -* There is a 240-minute provision request timeout; please reach out to us with the `provisionId` if requests remain pending for an extended period. ### When to Use Each Endpoint @@ -81,7 +80,7 @@ The following guidelines outline the best practices for working with the SAP Con ### Operations Best Practices -For regular user updates, use `PATCH` operations rather than `PUT` (full replace), whether for single user requests or bulk operations. This is the approach used by our large enterprise customers handling thousands of daily updates. +Use `PUT` only for initial user creation (or intentional full replacement of a user). Use `PATCH` for **ALL** incremental user updates. Reissuing `PUT` overwrites the user and removes all previous edits. This is critical: large enterprise customers handling thousands of daily updates exclusively use `PATCH` to avoid unintended data loss. #### For bulk updates (HR sync, daily changes) @@ -283,11 +282,7 @@ Use `/swagger` endpoint to retrieve the schema for error codes and messages at e ### Handling Long Pending Provision Requests -Currently the timeout for each provision request is 240 minutes. The provision request is marked as failure by the system if it exceeds the timeout. - -If you have a provision request that is pending for a long time, please reach out to us with the `provisionId` for investigation. The operation can be retried after the timeout based on the failure scenarios mentioned above. - -> **Note:** We have plans to reduce this timeout under 60 minutes. +Currently the timeout for each provision request is **120 minutes** (60 minutes in CCPS environments). The provision request is marked as failure by the system if it exceeds the timeout. The operation can be retried after the timeout based on the failure scenarios mentioned above. ## Events