#Salesforce Platform14 debatiendo

The first thing to check is whether the Flow is querying or updating records inside a loop. That can quickly become a problem as record volumes grow. 

A few things that usually help: 

• Move Get Records and Update Records operations outside loops wherever possible.
• Use record collections to process multiple records together instead of updating them one at a time.
• Filter queries carefully and retrieve only the fields and records you need.
• If the logic involves complex processing or large data volumes, consider Apex or Batch Apex. Salesforce Flow isn’t always the best fit for every workload.

One other thing to consider: if a significant part of the Flow handles lead-to-account matching or lead assignment, you may be able to move that responsibility to a dedicated tool rather than maintaining all the logic in Flow. LeadAngel, for example, handles lead-to-account matching, deduplication, and lead routing alongside Salesforce. That won't fix inefficient Flow queries directly, but it may help simplify the routing and matching logic your team needs to maintain. 

I’d start by checking the Flow’s debug details and identifying which queries or updates are consuming the most resources before deciding whether to refactor it or move part of the processing to Apex. 

You can automate most of this. Release updates are exposed in the Tooling API as the ReleaseUpdate object (API 50.0 and later), so they can be queried like any other data. 

A setup that works well: 

• A small scheduled job (a scheduled Apex class calling the Tooling API, or an external script or CI job) queries ReleaseUpdate once a week. 

• Store each result in a custom object keyed on the update's name, with its status and due date. New rows mean new updates. Rows that disappear or change status are the ones that "come and go". 

• Add a record-triggered flow on that object to email the admin team or create a Task when a new update appears or the due date is within 30 days. 

Keep the manual review for the actual decision, testing it in a sandbox before enforcing. The automation just makes sure nothing slips past.

@Amar Rawal

If this is your own Developer Edition org, there isn't a separate Salesforce admin you can contact—the org owner (you) is the administrator.

Unfortunately, if you can't reset your password because you don't remember the challenge/security question, there is no self-service way to bypass it.

Here are your options:

• First, try the Forgot Your Password? link on the login page and see if you can reset it using your registered email.
• If the reset process requires the security question and you can't answer it, you'll need to contact Salesforce Support. Since you can't log in to create a case, use the Salesforce Help site and choose the "Can't log in" or login/access support option, or use the contact options available there.
• If Salesforce Support can't verify ownership of the Developer Edition org, they may not be able to recover access. In that case, you may need to create a new Developer Edition org and reconnect it to your Trailhead account.

Hello @Michael Huang

• Confirm LWS state properly, since stale caching can make behavior look like it's tied to LWS when it's just browser cache — refresh + hard clear cache before trusting the repro. 
• Check whether the "close" the user triggers is the built-in header icon/ESC, or a custom button/action — if custom, that's expected behavior, not a bug.
• Check reactivity: if disableClose is set via mutating a property on an object rather than reassigning it, LWS's proxy membrane can silently swallow that mutation for cross-namespace objects — leading to disableClose never actually flipping to true from the modal's perspective even though your component "sees" it as true. That's a classic LWS mutation-alternatives issue and worth checking with the LWS Distortion Viewer.
• Verify ESC-key handling isn't attached at document/window level in a way that crosses the LWS namespace boundary (also part of the mutation/proxy troubleshooting docs).
• https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-troubleshoot.html