Skip to main content

#Architects10 discussing

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

2 answers
  1. Sep 20, 2:32 PM

    @Sai T

     

    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.

0/9000

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

1 answer
  1. Sep 16, 3:59 PM

    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/

0/9000

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

0/9000

💻 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. 💻 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 pr💬 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

2 comments
0/9000

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

3 answers
  1. Aug 5, 9:07 AM

    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. 

0/9000
0/9000

Ready to rethink how you build apps and experiences? 

 

Join Salesforce product experts @Shubhi Goyal, @David Green, Clay Martin, and @Julie Thompson for the next True to the Core Deep Dive to explore Salesforce Multi-Framework and the Headless Experience Layer (HXL), hear the latest product updates, and get your questions answered live. 

 

You'll leave with: 

✨ A better understanding of where app development on Salesforce is headed 

🛣️ A look at upcoming roadmap milestones 

💬 Direct access to the product team during an extended Q&A 

🤝 A chance to share your feedback with the people building the product 

 

➡️ RSVP here. ⬅️Ready to rethink how you build apps and experiences? #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

0/9000

💻 Recap of True to the Core Deep Dive: Lightning Design System 2 (SLDS 2)  

 

Thank you to everyone who joined True to the Core Deep Dive today, and to Salesforce Product Managers @Adam Doti, @Cliff Seal, and @Fiona Tang for sharing updates and answering your questions on SLDS 2. 

 

🎥 Missed the session? 

You can watch the full session on demand here. 

 

💬 Still have questions? 

Drop them in the comments below. We’ll do our best to get you answers! 

 

📝 Vote on future TTTC Deep Dive topics! 

Please take a moment to fill out this quick survey here to help shape future sessions. 

 

🔗 Resources shared during the session: 

🔹 Blog: The Admin Guide to Preparing Your Org for Dark Mode with SLDS 2

🔹 SLDS Linter Information

🔹 Design Systems on the RoadmapExchange

🔹 Trailhead Module: Dark Mode in SLDS 2: Quick Look

  

Have feedback on SLDS 2? Complete this survey to join the Salesforce Research Program and participate in SLDS 2 research. 💻 Recap of True to the Core Deep Dive: Lightning Design System 2 (SLDS 2) Thank you to everyone who joined True to the Core Deep Dive today, and to Salesforce Product Managers , , and for sharing upd #True To The Core @IdeaExchange #AwesomeAdmins #Salesforce Developer #Architects #DreamDesigners #DesignersMind

 

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

6 comments
  1. Jul 8, 5:08 PM

    Question on Dark Mode, is this optional or will it eventually be forced? Works great for some users but I literally can't see anything in dark mode. I have to have light mode to see.

0/9000

💻 True to the Core Deep Dive: DevOps Center Recap

  

Thank you to everyone who joined True to the Core Deep Dive today, and to Salesforce product leaders @John Belo, @Gilson Canario, @Karen Fidelak, and @Srikrishna Padmannagari for sharing updates and answering all your great questions.  

 

🎥 Missed it live? You can watch the full session on demand here.💻 True to the Core Deep Dive: DevOps Center Recap Thank you to everyone who joined True to the Core Deep Dive today, and to Salesforce product leaders , , , and for sharing updates and answering all💬 Still have questions? 

Drop them in the comments below. We’ll do our best to get you answers!  

 

📝 Shape future TTTC Deep Dive topics! 

Please take a moment to fill out this quick survey

about the session and help shape future session topics.  

 

🔗 Resources shared during the session:  

Read our DevOps blog on admin.salesforce.com to learn what’s new for admins: https://sforce.co/4vSa1Bx 

Review the official documentation for next-generation DevOps Center: https://sforce.co/4ebW9wd 

Explore the DevOps Center Quick Look on Trailhead: https://sforce.co/4eJEjRk 

Join the DevOps Center Trailblazer Community: https://sforce.co/3iKZ5pq 

Track upcoming enhancements on the DevOps Center public roadmap: https://sforce.co/4uKUTVP 

Watch the TDX session Optimize Release Management with DevOps Center: https://sforce.co/4en0JX9 

Watch the TDX session Streamline Release Management with the New DevOps Center: https://sforce.co/4ehVjg0

  

#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 @DevOps Center

0/9000

💬 Have a question about DevOps Center? Bring it to our next True to the Core Deep Dive on June 16. 

 

Join Salesforce product experts @John Belo, @Gilson Canario, @Karen Fidelak, and @Srikrishna Padmannagari for a Q&A-focused conversation on the future of Salesforce DevOps and what it means for admins. 

 

Here’s what you can expect: 

💬 Open Q&A with Salesforce product experts 

🚀 Insight into upcoming features and enhanced delivery experiences 

⚙️ Practical guidance for evolving your deployment strategy 

💡 A chance to share feedback directly with the product team 

 

➡️ RSVP and join the conversation. ⬅️ 💬 Have a question about DevOps Center? Bring it to our next True to the Core Deep Dive on June 16. #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

2 comments
0/9000