What's new on Salesforce Break:
Winter '27 Flow Tips Every Admin and Developer Needs Right Now(YouTube)
Collection Filter Criteria Resource in Salesforce FlowKeep Business Logic Outside Your Flow
#Flow #Flows #New Releases #Architects
Collection filters flew under the radar in this release, but is probably my favorite feature. Going to be very useful.
Does anyone know the right trailhead mix for it? It shows as “Architect Journey: Sharing and Visibility” on the link on the exam guide.
#Trailhead #Certifications #Certification #ArchitectsSharing and Visibility Architect was my first architect cert and one of my favorites! Here is the trailmix link, it is working for me: https://trailhead.salesforce.com/users/strailhead/trailmixes/architect-sharing-and-visibility
Hi everyone,
I’m looking for some architectural input on a record visibility design for a multi-subsidiary arquitecture.
Context:
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.
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:
Fixes, in order of preference:
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 groups
If 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.📣 刷新された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/
■ 対象
認定システムアーキテクトまたは認定アプリケーションアーキテクトの資格をお持ちの方
@Salesforce Developers Japan
#Architects
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.
#Salesforce CPQ & Billing #CPQ #CPQGurus #CPQAskAnExpert #Salesforce Developer #Architects
Thank you for your response. This is the recommendation I gave as how to move forward with this change.
If you had to have some mechanism to determine the existing current structure versus the new what would you use? For example we have a Year in Contract field for the current structure which is a formula field but that doesn't say whether a contract is new or existing. I wonder if we should create a field on the backend that we update via an upload that flags a contract as "Legacy"/"Existing" new. Just trying to think of the best approach so that the automation will know that a contract is existing or new so we don't accidentally take the interim renewal and try to convert it to the new structure. We do have a field called Upcoming renewal type that says Subscription Renewal or Contract Renewal. I think we can use that to say basically exclude subscription renewal and look at the ones that are contract renewal.
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--
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
Hi Piyush,
1. You're right, mTLS is the wrong tool here. mTLS operates at the application/TLS layer after a TCP connection is already established — it proves identity to something that's already listening and accepting connections. If the vendor's firewall is dropping packets before that handshake even starts, no client cert changes that. mTLS solves "who is this," not "can this even reach me."
2. Private Connect is AWS PrivateLink-based only, so it's natively usable when the target sits in an AWS VPC. Azure targets aren't natively supported — you'd need inter-cloud private peering (AWS↔Azure via ExpressRoute/Direct Connect + a transit arrangement) which Salesforce doesn't self-serve; that requires your account team and is a heavier lift. No public roadmap confirmation of native Azure PrivateLink support as of now.
3. No native mechanism gives an Apex callout a narrower/tenant-specific egress identity beyond the published IP ranges — that's the actual gap you've identified. The published Hyperforce ranges are deliberately shared infrastructure-wide, not per-org, so it's a network-layer allowlist, not an identity boundary. There's no equivalent of "static NAT per org" for outbound Apex callouts today.
4. Yes — a relay/gateway in front of the private service is the standard, recommended pattern here, and I'd recommend it. Put a lightweight reverse proxy (or MuleSoft Anypoint, or even a small managed API gateway) in a publicly reachable spot the vendor controls, with the vendor's actual private-network service sitting behind it. Salesforce calls the gateway over the public internet (allowlist-friendly, small surface), and the gateway — sitting inside the vendor's trusted network — forwards to the private endpoint. This gets you real identity-based control (API key, mTLS, OAuth — now actually meaningful since the gateway is an app-layer listener) instead of a shared-IP-range network allowlist, and it decouples you from Salesforce's outbound range changes entirely, since your callout target becomes a stable endpoint the vendor owns. This is what most orgs land on for exactly this scenario — it's a small piece of infra to own, but it's the durable fix.
Reference:
https://unofficialsf.com/understanding-private-connect/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
💻 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:
#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
Hi Trailblazers,
With the secure-by-default changes introduced in API version 67.0, Apex database operations (SOQL, SOSL, and DML) now run in User Mode by default. This automatically enforces Object-Level Security (CRUD), Field-Level Security (FLS), and record sharing rules without requiring explicit keywords on every query.
Given this platform shift, do we still need to worry about using Schema classes (like Schema.sObjectType.Account.isAccessible()) for security checks?
I am trying to understand if there are edge cases where manual Schema checks are still required, or if modern alternatives like WITH USER_MODE, AccessLevel.USER_MODE, and Security.stripInaccessible() have made manual schema verification completely obsolete.
I'd love to hear how other architects and developers are adjusting their coding standards and security frameworks for API 67.0+.
Thanks in advance for your insights!
#Salesforce Developer #Architects
#Trailhead Challenges #Security #Apex
Hi @Yash Gurharikar -
Not completely. User Mode removes a lot of the manual security boilerplate, but the Schema class still has valid use cases.
For example, it's still useful for dynamic Apex, conditional UI/business logic, metadata-driven frameworks, or when you need to check access before performing an operation. In most new Apex code, prefer User Mode and Security.stripInaccessible(), and use Schema only where those APIs don't cover your scenario.
If you are an architect, admin or developer looking to revamp your security in your salesforce org and looking to make decisions on record types, dynamic forms and page layouts, my blog provides you the smart framework which will help you to decide on when to keep page layouts, dynamic forms and record types.
@Architect Group, Atlanta, US @Architect Group, Orlando, US@Architect Group, Columbus, OH, US@Architect Group, Chennai, IN@Admin Group, Philadelphia, US@Architect Group, London, UK@Admin Group, Philadelphia, US @Admin Group, Mount Laurel, US@Admin Group, Columbia, MD, US@Admin Tricks@Admin Addicts@Marketer Group, Philadelphia, US
#Architects #Security
