Start a conversation Sign in
Start a conversation
  1. CloudSense Support
  2. CloudSense Articles
  3. Articles

Salesforce Integration User Password Rotation with CloudSense (Connected App + OAuth 2.0 JWT)

Overview

If you are planning to rotate the Salesforce password for one or more integration users (TEST/UAT/PROD), CloudSense-side coordination is typically not required when CloudSense is using a Salesforce Connected App with the OAuth 2.0 JWT Bearer Flow.

In this model, CloudSense obtains access tokens using a signed JWT assertion “as” the integration user and does not store or authenticate with the user’s Salesforce password, so changing that password should not impact CloudSense services.

Key Information

  • Standard CloudSense connectivity uses a Salesforce Connected App and OAuth 2.0 JWT Bearer Flow (signed JWT assertion) to request an access token as the integration user.
  • CloudSense does not store or send the integration user’s Salesforce password for standard connectivity.
  • Therefore, rotating the Salesforce password does not affect CloudSense connectivity, provided the following remain unchanged:
    • The Connected App remains installed and correctly configured.
    • The integration user remains active (not locked/frozen).
    • The integration user remains authorized/pre-approved for the Connected App (as applicable).
    • Permissions and JWT/certificate configuration remain valid and unchanged.
  • No error was reported for this scenario because it is a planned change. If authentication is misconfigured, you may see 401 / Unauthorized-type errors (for example: "service=cloudsense.http.eapi status=ERROR errorCode=401 errorMessage=Unauthorized"), which typically point to Connected App/JWT/certificate/authorization issues rather than a password issue.
  • Password rotation can impact customer-managed integrations that use username + password (and possibly a Salesforce security token), such as middleware, custom jobs/scripts, or other connected systems configured for password-based authentication.

Customer Impact

No CloudSense maintenance window, credential update, or CloudSense-led post-change validation is required for password-only rotations when using the standard Connected App + JWT flow.

To avoid downtime in customer-managed integrations, complete the following:

  1. Inventory credential usage: Identify every system/job that references each integration user (middleware, schedulers, custom scripts, secret vaults, SFCC or other connected systems, etc.).
  2. Confirm the authentication method per integration:
    • If it uses Connected App + JWT → password rotation should not affect CloudSense.
    • If it uses username/password (+ security token) → update the stored secret(s) after the password change.
  3. Rotate passwords in Salesforce for each integration user (per environment).
  4. Update customer-managed systems (if applicable): Update stored passwords (and security tokens, if used) wherever they are referenced.
  5. Run customer smoke tests for business-critical workflows (examples commonly used: open/create a basket, run “Calculate Totals”, catalogue synchronization, create/submit an order if part of your validation).
  6. Monitor for authentication failures: Review relevant logs in Salesforce, middleware, and connected systems; where relevant, also check client/browser console and network activity during validation flows.

Frequently Asked Questions

1. How can I tell whether CloudSense uses my integration user’s Salesforce password?
If your integration uses a Salesforce Connected App with OAuth 2.0 JWT Bearer Flow, CloudSense authenticates via a signed JWT assertion and does not store or use the user’s Salesforce password. Password rotation should not affect CloudSense connectivity in that model.
2. Do I need to schedule an after-hours maintenance window for the password reset?
Not for CloudSense services when using the standard Connected App + JWT flow, because password changes do not affect CloudSense authentication. Consider an off-hours window only if your downstream systems (middleware/custom scripts/SFCC configurations, etc.) rely on username/password authentication and require coordinated updates.
3. Who should perform post-change testing?
Post-change validation should be performed by the customer, focusing on business-critical workflows (for example basket operations, “Calculate Totals”, catalogue sync, and any integrations you operate). CloudSense participation is not required for password-only rotations under the standard JWT model.
4. What should I update if we have middleware or custom jobs using the integration user?
Update the stored secret(s) in the customer-managed system(s) (configuration files, secret vault entries, scheduled job parameters, SFCC service credentials, etc.) wherever the old password (and possibly Salesforce security token) is referenced, then rerun your integration smoke tests.
5. What if we start getting “401 Unauthorized” after changing the password?
A 401 / Unauthorized typically indicates an authentication configuration issue (Connected App authorization, JWT/certificate configuration, user status/permissions) or a customer-managed component still using the old password. Re-check Connected App/JWT configuration (including the JWT subject/user mapping) and confirm all password-based consumers were updated with the new password (and security token, if applicable).
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Matej Storga

  2. Posted
  3. Updated

Comments