#Answers7 debatiendo

Setup

Enterprise Territory Management, Unlimited Edition. ~59K Accounts across 16 regions. Account OWD is open and must stay open — reps need to find and identify any account.

This applies to our Sales User profile only (~150 users). Support, Customer Success, SE, Deal Desk, Finance and leadership keep full visibility through an exemption.

The requirement

Accounts stay visible to everyone, but a set of sensitive revenue fields — Acc ACV, ARR, TBookings, Soft ACV, Dec ACV Rollup, VEc counts — must be visible only to sales users in that account's own region. That includes list views, reports, search and the API, not just the record page.

All of them are Currency or Number. Some are stored, some are formulas, two are roll-up summaries from Opportunity.

The problem

Field-level security is resolved per user, not per record. A field is visible to a user on every Account or none. Nothing in the sharing model makes a field's visibility depend on the record being viewed — and I can't restrict the record itself, because the account has to stay globally visible.

What I'm currently considering

Hide the real fields with FLS from the Sales User profile, then expose one formula field per metric that only returns a value when the user's region matches:

Account_ARR_Regional__c  (Currency)  =    IF( $User.Region__c = Region__c, Account_Arr__c, NULL )

User.Region__c would be read-only for sales users and populated from our territory roster. This needs ~15 fields and keeps everything native, but it leans on $User inside a formula, which makes the field non-deterministic and non-indexable — and I'm not sure how that holds up at 59K records.

I've also looked at a child object with its own private sharing, and at per-region or per-geo shadow columns. Each trades away something different — list views, reports, search, or field count.

My question

How would you approach this? I'd genuinely rather hear what people have actually built than have my own idea validated.

Specifically, if you've solved per-record field confidentiality in a real org — what did you land on, and what did it cost you a year later in maintenance?

And if the $User formula approach is a bad idea for reasons I haven't hit yet, I'd like to know before I build 15 of them. 

#Answers  #Salesforce Developer  #Metadata  #Territory Modeling  #Sales Cloud

Setup

Enterprise Territory Management, one active model: 3 Geography nodes → 16 Region nodes → ~50 Territory → ~19 Sub-Territory. ~ Opportunities, ~ Accounts, 99.96% of which are assigned to a territory.

Opportunity OWD is already Private, but View All is granted on ~ profiles, so everyone effectively sees every region. We're removing it and replacing it with region-scoped access.

Phase one targets our Sales User profile only (~155 users). Sales managers sit on that same profile, so manager visibility has to come from the territory hierarchy rather than a separate profile. Everyone else keeps View All via a bypass permission for now.

Where I've got to

My plan was:

1. Stamp a stored field Visibility_Region__c on Opportunity before save.
2. Create 16 criteria-based sharing rules — Visibility_Region__c = 'X' → share with Territory X and Subordinates.
3. Check UserTerritory2Association before letting a sales user create an opportunity out of region.

Then I noticed our territories already have OpportunityAccessLevel set, and accounts are almost fully assigned — so native ETM territory sharing would already give us region-scoped access once users are assigned, without any of the above.

The reason I'd built the stamped-field approach is that our region isn't always the account's region: an opportunity can carry an MSP end-user region or a manual override that should win. Native ETM only keys off the account. But that's 1.8% of our opportunities — the other 98% would be handled natively.

My questions

1. Is the stamped field + 16 sharing rules the right call here, or am I overbuilding? Would you lean on native ETM territory access for the 98% and handle the override cases some other way — manual shares, apex sharing, an opportunity team — rather than building a parallel mechanism for all records?

2. How would you handle lead conversion? Conversion creates Opportunities too, and the only hook is Opportunity beforeInsert. addError() there rolls back the entire conversion, destroying the Account and Contact the user just created. What I want is to let the conversion complete but withhold only the Opportunity, then route it to the account owner. I'm considering a screen flow replacing the standard Convert button with createOpportunity = false on the out-of-region branch — is that what people actually do?

3. One factual check: when addError() fires on the Opportunity during convertLead, does the whole transaction roll back cleanly, or can it orphan the Account/Contact?

Any views on territory assignment level — region node versus the specific territory a rep owns — would also be welcome. 

Hi Everyone,

We are currently evaluating a significant change to our Salesforce data model and would appreciate guidance from anyone who has implemented a similar solution in a large enterprise environment.

Current Situation

The Account object is our primary master data entity.

 Looking for Experience and Best Practices: Splitting Salesforce Account into Separate Business Entities (Commercial Account vs Legal Entity) 

If your organisation has implemented a similar transformation, we would greatly appreciate insights on:

1. Recommended target architecture.
2. Expected level of effort.
3. Biggest implementation risks.
4. Business processes that were unexpectedly impacted.
5. Integration challenges discovered after design.
6. Impact on CPQ, contracts, billing, and reporting.
7. Data migration strategy and lessons learned.
8. Account Hierarchy Impact  
   How did the change affect:
   • Parent Account hierarchies
   • Rollup reporting
   • Account Teams
   • Territory Management
   • Enterprise Account structure
9. How were Opportunities handled?  
   Did Opportunities relate to:
   • Commercial Account
   • Legal Entity

Any reference architectures, lessons learned, implementation patterns, anti-patterns, or best practices would be extremely valuable.

Thank you in advance for sharing your experience and recommendations. 

#Answers #Salesforce Admin #Sales Cloud