Hi everyone,
I’m looking for some architectural input on a record visibility design for a multi-subsidiary arquitecture.
Context:
- Account and Quote OWDs are set to Private.
- An ERP integration creates Quote records linked directly to QuoteAccountId (field when you activate the feature "Create Quotes without Opportunities"
- All sales users share the same Profile and Role and public groups BUT
- Field Sales users should only see Quotes linked to Accounts they own, provided the Quote and Account regions (e.g. Spain, France, etc.) match.
Current Solution:
To distinguish Field Sales users from back-office users, I created dedicated Public Groups per region (e.g. Group_FieldSales_RegionA, Group_FieldSales_RegionB).
A Record-Triggered Flow checks whether the Account Owner belongs to the corresponding Field Sales group. If so, the Flow creates a QuoteShare record for that user.
Importantly, these Public Groups created for the Field Sales users are not used in Sharing Rules
. They are only used by the Flow as an internal validation mechanism to identify whether the Account Owner is a Field Sales user. This is also important for managers with hybrid responsibilities, who may belong to both Field Sales and back-office groups (they are everywhere in every public group with execption of my newly created Field Sales public groups)
Architectural Question:
There is a concern of non-developer members about using Public Groups and believes visibility should be based purely on Account Ownership.
- Would you consider using Public Groups as an internal identity/validation mechanism in Flow a sound architectural approach in this scenario?
- If Public Groups cannot be used, what would be a robust alternative for a Flow to identify Field Sales users, given that Profiles, Roles and public groups are shared and some users have hybrid responsibilities (Sales Managers are inside and outside at the same time)?
I’d appreciate your thoughts on the best practice for this design.
Thanks in advance!
@Salesforce Administrators & Developers, @Salesforce Administrators and Developers, @APAC Architects, @Data Quality & Management, @Ladies Be Architects
#Trailhead Challenges #Trailhead #Salesforce Developer #Salesforce Admin #Solution Architects #Architects #Enterprise Architecture #Flow #Security
You're right the business rule doesn't care who owns the Quote. The risk comes from how the platform stores the share, not from the rule.
Where the Quote owner matters (platform mechanics, not business logic)
A Flow created QuoteShare is a manual share (row cause "Manual"). Salesforce deletes manual shares on a record when that record's OwnerId changes. Your Flow most likely triggers on events like Quote created or Account owner changed. A Quote owner change isn't one of those events, so:
- The ERP (or a user or mass transfer) changes the Quote's owner.
- The platform silently deletes the share the Flow created.
- Nothing re-runs the Flow, so the Account Owner loses access even though the business rule says they should have it.
Fixes, in order of preference:
- Add a trigger path on Quote update when OwnerId changes, so the Flow recreates the share.
- Add a scheduled reconciliation that compares expected and actual shares. This also catches other drift.
A related edge case:
if the Account Owner is also the Quote owner, they already have access. The Flow should skip creating the share in that case, because inserting a share for the owner is rejected or ignored.
If the ERP never changes Quote ownership(it creates Quotes under a fixed integration user and never updates them), this risk mostly goes away, and the Account owner, region, and bulk-load gotchas are what remain. I can't confirm that from here, so it's worth asking the ERP team.
On the permission set groupsIf every sales user is in the same Permission Set Group, that group can't tell Field Sales from back-office, so it doesn't help as the identifier. Option 2 only works with a separate, standalone permission set (for example
Field_Sales_Spain) assigned directly to Field Sales users and not included in the shared group. Hybrid managers just get that one assigned too.
