#Automation49 utenti parlano di questo argomento

Your instinct about the screen flow is right, and it doesn't have to need a developer. 

The core issue is that sharing is all-or-nothing at the record level. Once line B can see a line A Account, it shows up in every report, list view and search. You can't share a record for one screen but hide it in reports. 

So flip the approach: 

1. Remove the sharing rule, so line A Accounts stay private to line A. 

2. Build the screen flow you mentioned, launched from a button on the Opportunity, and set it to run in "System Context Without Sharing". The flow can read the line A record through your lookup and display only the specific fields line B needs. 

3. Show it on the Opportunity page as a screen flow component or quick action, so there are no reports and no broad visibility. 

Watch out: system context also bypasses field-level security. Be deliberate about which fields the flow displays, and document it for your security or audit team (relevant at a firm like yours). 

If line B also needs to report on that information, add a small custom object or a few fields on the Opportunity, filled by a record-triggered flow with a copy of just the fields they need. That gives line B something reportable without opening up the Account.

Chris's set idea is the right way, I built it on Superstore to make sure it really drives the zone (screenshots below). A few details that made it work:  

Create a set on Mission ID (right-click the field > Create > Set) and use it in place of the Mission ID filter, so every sheet that was filtered by Mission ID now has the set on Filters showing IN. Then right-click the set > Show Set, and on the card's menu choose Single Value (dropdown). For your users it looks almost the same as the dropdown they have now, the only difference is there's no (All) option in single value mode.  

Keep the set dropdown outside the container you hide. If it sits inside it, it disappears with the section and nobody can switch back.  

The visibility field must be one value for the whole workbook, so the whole comparison goes inside the braces:  

{ FIXED : COUNTD(IF [Mission ID Set] THEN [Milestone Rank] END) > 0 }   

Written as { ... } > 0 it won't show up in the list, that's the bit Chris mentioned. And because it's a FIXED, normal filters don't affect it. If another filter on the dashboard should count too (date, region...), right click it and Add to Context.  

Put the milestone sheets in one tiled container, select the container, go to the Layout tab, tick Control visibility using value and pick the field. When it's False the container goes away and the tiled items around it take the space, so no blank area.  

In my test the field is "does the selected state have any order with a 50% or bigger discount": Texas shows the section, California hides it. Same structure as yours, just swap in Mission ID and Milestone Rank.  

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. 

Hi Alessandro,

Regarding your design pattern for preserving historical audit records from short-lived staging sources in Data Cloud, here are the technical confirmations for how PySpark Custom Code Extensions handle write operations: 

1.WriteMode.APPEND Execution:Append Behavior. 

When using client.write_to_dmo(..., write_mode=WriteMode.APPEND), PySpark strictly appends new incoming rows to the target Data Model Object (DMO) or Data Lake Object (DLO) without truncating or wiping existing data. It will never automatically rebuild or clear out historical rows. 

2.Immunity to Full Refreshes:Platform Independence. 

PySpark code execution is completely separate from the platform-managed Full Refresh schedules used by standard UI Batch Data Transforms. Data Cloud will not automatically trigger a full rebuild or drop table operation on targets populated via Custom Code Extensions. 

3.WriteMode.MERGE and Source Deletions:Merge Behavior on Deletions. 

Under WriteMode.MERGE, records that are deleted or purged from the source staging table remain untouched and preserved in the target table. Merge updates or inserts matching records based on keys, but it does not propagate source deletions to remove historical records from the target.

Hi @Nich Weidman

When Salesforce sends a system email, it includes special header fields that identify the source organization and user. To identify the source, locate the following fields in the raw email headers:

• X-SFDC-LK — The Salesforce Organization ID (the 15- or 18-character org ID of the org that sent the email).
• X-SFDC-User — The Salesforce User ID of the user whose automation triggered the email.
• X-SFDC-EntityId — The record ID of the Salesforce entity (such as a workflow rule or report) that triggered the email.
• X-SFDC-Emailcategory — The category of the email (for example, workflow, report, or Chatter digest).
• X-SFDC-ORGTYPE — The type of org that sent the email. Note: this field only appears in emails sent from Free or Trial orgs. It does not appear for production, sandbox, or developer org emails.

Important:

Use the original .msg formatted email — not a forwarded copy. Forwarding an email overwrites the original headers, making it impossible to identify the source org. 

Find the User Id from

then go to set up and add a Debug trace for the user and then triggert the email. This will create a debug log for you to read and find the source. 

Check out these articles for more info:

1. Find the email headers for emails
2. How to Identify the Salesforce Organization That Sent a System Notification Email