#Architects12 人がディスカッション中

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.

1. Would you consider using Public Groups as an internal identity/validation mechanism in Flow a sound architectural approach in this scenario?
2. 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! 

📣 刷新されたWell-Architectedを体験しよう！〜 AIアーキテクチャ ワークショップのご案内

【東京オフィスでの現地開催です。懇親会もあります！】

Agent時代のアーキテクチャを一緒に学びましょう！

Dreamforce 2026で大きく刷新されたSalesforce Well-Architectedを、解説＋ワークショップで体験いただけるセッションを開催します！（ Partner Days 内の企画ですが、一般ユーザー企業の方も参加OKです。）

■ 申し込みフォーム（詳細はこちらのフォームをご確認ください）

https://docs.google.com/forms/d/e/1FAIpQLSccWR7criKJIHiZlBme16hPTOI8BeFayCRFygNfHdztu7nBfQ/viewform

■ 日時

2026年10月26日（月）15:30〜17:00 

■ 場所

Salesforce 東京オフィス

https://www.salesforce.com/jp/company/direction/

■ 対象

認定システムアーキテクトまたは認定アプリケーションアーキテクトの資格をお持ちの方

Hello, 

Currently our system is built that upon the creation of a quote for a new sale they set a custom Contract Term field on the quote to the length they want the term to be (for example, 36) and then on the quote they set the Subscription Term to 12. They have automation that then creates a Master Agreement that is a high level agreement that contains the full length of the contract (for example, start date of 1/1/2026 through end date 12/31/2029) and on the master agreement the contract term says 36. And then there is a child agreement that is related to the master agreement (a child to this agreement) that has a contract term of 12 and a start date of 1/1/2026 through 12/31/2026. Then on 12/30/20206 they create a new Subscription Agreement via an auto renewal process for Year 2 with dates of 1/1/2027 through 12/31/2027. Then do the same thing at Year 3 for dates of 1/1/2028 through 12/31/2028. Then on 1/1/2029 they complete what is called a contract renewal where the above starts over again with a new master agreement then child subscription agreements. 

Now with a new sales they want to move to a quote with the custom contract term of 36 months and subscription term of 36 months but within the quote are quote line groups for Year 1, Year 2, Year 3 of 12 months. When the contract creates they want one contract containing the whole contracts information. Then at the end of the 3 years the "contract renewal" occurs for the 36 months for the contract term and Subscription Term. 

The issue is existing contracts on the old structure. How do we handle the interim subscription agreements before the contract renewal if we remove the master agreement. And then how do we move to the new contract renewal process at the end of the compete term. I am assuming some sort of data migration but not sure what that would be or would look like. 

Has anyone else had to go through this? And nope they do not want MDQ. 

Thank you. 

We make outbound Apex callouts from a named credential to a vendor API. The vendor has moved that API onto a private cloud network, and our callouts now fail at the network layer before auth is ever evaluated. 

The only working solution we've found is for the vendor to allowlist Salesforce's published Hyperforce outbound ranges from https://ip-ranges.salesforce.com/ip-ranges.json (per KB 003876184, which explicitly recommends an IP allowlist for outbound Apex callouts since Salesforce outbound IPs may not resolve under *.salesforce.com). 

That works, but it has two drawbacks we'd like to avoid: the ranges are shared across all Salesforce tenants on that infrastructure, so it's a weak control rather than a real identity boundary and Salesforce advises allowlisting the entire file, which is a broad and evolving surface for the vendor's security team to accept. 

What I'm hoping someone has solved before-- 

1. Salesforce's stated preferred alternatives are mTLS and domain allowlisting, but both assume the far side is filtering at the application layer. When the block is network-level, a client certificate doesn't get you through the firewall. Has anyone actually used mTLS to solve a reachability problem rather than an auth one, or am I right that it's the wrong tool here?
2. Private Connect / Outbound Network Connection appears to be AWS PrivateLink only. Can anyone confirm whether Azure-hosted targets are supported, now or on the roadmap?
3. Is there any other mechanism to give an external endpoint a stable or narrower egress identity for Apex callouts?
4. For those who've hit this: did you end up putting a relay/gateway in front of the private service and pointing Salesforce at that instead? Would you recommend it?

Any experience appreciated, we have a go-live this week, so we're proceeding with the allowlist for now and looking for something more durable after. 

Articles that I have already read - 

1. https://help.salesforce.com/s/articleView?id=003876184&type=1

2. https://help.salesforce.com/s/articleView?id=000384438&type=1

#Salesforce Developer  #Architects  #Solution Architects  #TrailblazerCommunity  #Security  #Integration

I have created 1 Orchestration Flow. It is breaking for 1 one of the Activity on the Connect Portal. 

If I am running the Orchestration Flow outside of the Connect Portal then it is working fine and giving me the respected output. 

I am working in 3-4 sandboxes but only on 1 sandbox it is giving me the following error.  

An Error Occurred with Your "Project Approval Flow" Orchestration

You’ve received this email because an error occurred while your "Project Approval Flow" orchestration was running. 

View debugging information for this orchestration in Flow Builder.

Error element Submit_for_Approval5 (FlowOrchestratedStage). 

An error occurred. Try again, or contact Salesforce Customer Support and provide this error ID: 53194206-372493 (1440708959)  

Can anyone help me with this. 

Is any permission or something is missing for the connect portal because of that it is not working. 

Need to find the solution asap. 

#Customer Service  #Flow-Orchestration

#Flows #Salesforce Developer #Architects

💻 True to the Core Deep Dive: Salesforce Multi-Framework and Headless Experience Layer Recap

Thank you to everyone who joined today's True to the Core Deep Dive, and a special thanks to Salesforce product leaders @David Green, Clay Martin, and @Julie Thompson for sharing the latest updates and answering your thoughtful questions.

🎥 Missed the session?

 Watch the full episode on demand here. 💬 Still have questions?

 Drop them in the comments below, and we'll do our best to get you answers.

📝 Help shape future TTTC Deep Dive sessions! 

Take a minute to complete our feedback survey and let us know what topics you'd like to see next: 

https://sforce.co/tttcddfeedback

🔗 Resources shared during the session:

• Read the Salesforce Developers blog to learn how to build React apps with Salesforce Multi-Framework, now generally available: https://sforce.co/4yKe7hx
• Explore the Headless Experience Layer Playground to experiment with Salesforce Headless 360 capabilities: https://sforce.co/44TRtpj

#True To The Core @IdeaExchange #AwesomeAdmins #Salesforce Developer #Architects

@Salesforce Admins Live Sessions, @* Release Readiness Trailblazers *, @* Salesforce Platform *, @* Trailhead Official *, @Trailblazer Community Cove, @Admin Addicts, @* Salesforce Developers *, @Dreamforce for Admins, @Architect Trailblazers