#Salesforce171 personnes en discutent

こんにちは、 

これは公式のSalesforceドキュメントで確認できた事例ではありませんが、画像のパターンから判断すると、ページのCSS（スタイルシート）が正しく読み込まれず、ブラウザのデフォルトスタイルが表示されている可能性が高いです。「ユーザー名」「パスワード」が実線で囲まれた形で表示されるのは、HTMLの<fieldset><legend>要素にCSSが適用されない場合のブラウザ標準（未装飾）表示によく見られるパターンです。 

確認・対処方法： 

1. シークレットウィンドウ（Ctrl+Shift+N）で同じログインページを開いて再現するか確認 — 拡張機能やキャッシュの影響を切り分けられます。 

2. Chrome拡張機能（特に広告ブロッカー、翻訳ツール、WhatFixなどの業務用拡張機能）を一時的に無効化して再読み込み — 拡張機能がページのCSS読み込みを妨げているケースが報告されています。 

3. ブラウザのキャッシュとCookieをクリアしてから再読み込み。 

4. 会社のプロキシ／セキュリティソフトが外部CSSリソースをブロックしていないか、社内IT部門に確認（企業ネットワーク環境でよくある原因です）。 

上記で解決しない場合は、具体的な原因を断定できる公式情報が見つからなかったため、Salesforceサポートへの問い合わせをおすすめします。

Hi @Irfan Shaikh

This is a Service Cloud Voice + Genesys Cloud CTI integration issue sticking to the Salesforce side of the diagnosis since that's where the fix will need to land. 

First, a correction to Genesys's suggested fix: in your second screenshot, "Enhanced Omni-Channel Routing" is already toggled On (top right). So that isn't your problem Genesys support's suggested step doesn't apply here, and chasing it further will be a dead end. 

What actually points to the real cause: the response body shows "signedToken": "UNAUTHORIZED" on a 400 Bad Request from the /sfdc/liveagent/rest/presence call, wrapped by a Spring WebClient error (that's coming from the GC-for-SCV middleware layer calling into Salesforce). That specific field - signedToken combined with the fact this broke immediately after your self-signed certificate renewal, points to a certificate/Connected App mismatch, not a feature toggle. The Genesys Cloud → Salesforce presence call is authenticated via a JWT signed by a certificate that Salesforce's Connected App has to trust. If the cert was regenerated on both ends independently, it's very possible the public certificate now registered in Salesforce's Connected App doesn't match the private

key Genesys is currently signing with (or vice versa) a very common miss when a cert is rotated on both sides at once rather than one side generating it and sharing the public half.A few caveats worth flagging directly:  

1. Identify the Connected App used by the integration 
   In Salesforce Setup → App Manager, find the Connected App tied to the Genesys Cloud / GC for SCV integration (search 'Genesys' or check the Call Center / telephony integration config for which Connected App it references).

2. Check its digital signature certificate 
   Open that Connected App's OAuth policy settings and look at 'Use digital signatures.' Note the certificate currently uploaded there this is what Salesforce trusts to validate incoming signed tokens.

3. Compare against what Genesys is signing with now 
   In Genesys Cloud's Salesforce integration config, confirm which certificate/private key it's using to sign the JWT since the August 18 renewal. If this doesn't match the public cert in step 2, that's your 401/UNAUTHORIZED root cause.

4. Re-upload the correct certificate 
   If mismatched, export the current public certificate from whichever side generated the new one, and upload it to the Connected App's digital signature setting in Salesforce (or update Genesys's config to sign with the cert Salesforce actually trusts).

5. Also check Certificate and Key Management 
   Separately, in Setup → Certificate and Key Management, confirm the old expired cert isn't still referenced anywhere else in the org (e.g. an Auth Provider or External Client App tied to the same integration) a stale reference here can cause the same symptom even after fixing the Connected App.

6. Re-test agent login after alignment 
   Once certs are confirmed matching on both ends, have an agent attempt Omni-Channel login again and re-check the Network tab response for the presence call you should see a 200 instead of the signedToken UNAUTHORIZED response.

• I haven't verified any of this against your actual org config no MCP/org access in this session, so this is diagnosis from the evidence in your screenshots plus how Salesforce's Omni-Channel CTI presence API and Connected App JWT auth normally work. Treat the connected-app-name and exact settings as "go look here," not "this is confirmed."
• Genesys already ruled out their own side (200 OKs on their APIs), and your screenshot rules out the Enhanced Omni-Channel toggle (already on) that narrows this to a trust/verification failure on the Salesforce side specifically for the token Genesys is now signing, which is exactly what a mismatched cert after a dual-side rotation produces.
• If step 1–2 turn up something other than a Connected App (e.g. this integration uses a different auth mechanism like a Named Credential or an External Client App instead), tell me what you find and I'll adjust the presence-endpoint auth pattern varies slightly depending on how GC-for-SCV was originally packaged/installed in your org.

If you can pull the Connected App (or equivalent) config, share what's there and I'll help pinpoint the exact mismatch. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

@Deepak Sharma 

Best practice is a Trigger Handler pattern with controlled recursion, rather than relying only on a static Boolean. 

•  Keep triggers thin and move logic into handler/service classes. 
•  Use a static Set<Id> to track records already processed in the current transaction. 
•  Keep all logic bulkified—use collections and avoid SOQL/DML inside loops. 
•  Add clear entry conditions so updates only happen when relevant fields actually change. 

A static Boolean can work for simple cases, but a

is more scalable for complex automation. 

@Deepak Sharma

I would use an after-trigger for all four events because the Account tier depends on the current set of Opportunities. Insert and undelete can introduce a qualifying Opportunity, update can change Amount, Stage, or Account, and delete can remove the Opportunity that previously determined the tier.  

For update, I collect both the old and new Account IDs so that an Opportunity moving between Accounts recalculates both Accounts.  

The handler passes a Set of Account IDs to a service class, which performs bulk SOQL, calculates the highest applicable tier in memory, and performs a single bulk Account update. This avoids SOQL and DML inside loops and handles bulk transactions safely.