Introducing the Salesforce Architecture Blog: Community Author Program

Every day, Salesforce Architects across the ecosystem are solving complex challenges, exploring new patterns, and helping define what the next generation of enterprise architecture looks like. As they build the Agentic Enterprise, shared experiences, real-world insights, and lessons learned help the entire community learn, grow, and innovate. 

The Salesforce Architecture Blog is a place where architects come to learn, challenge their thinking, and discover what’s possible. Now we’re expanding the voices shaping that conversation. 

We’re excited to introduce the Salesforce Architecture Blog: Community Author Program. Real architects. Real insights. Real impact.

Submissions open June 1, 2026. Read on for program details and submission guidance.

What is the Salesforce Architecture Blog: Community Author Program?

The Salesforce Architecture Blog: Community Author Program is an opportunity for Salesforce Architects to contribute to the Salesforce Architecture Blog, the same channel where the community already comes for real-world perspective, architectural guidance, and innovative thinking on what it means to build and design like a Salesforce Architect.

This isn’t about adding more content. It’s about adding more voices. Voices from the field, from real implementations, from architects who have navigated complexity, made hard trade-offs, and built something worth sharing. Just as community members share their expertise at events and in conversations, this program creates a new opportunity to do the same, one that lives permanently, reaches the full community, and connects your experience to the people who need it most.

Bring real-world insights to the community

We’re looking for submissions grounded in real implementation experience, including practical insights, architectural decisions, lessons learned, and patterns others can apply. Strong submissions will reflect lived experience, not just theory. Here’s what we have in mind:

• Pilot and beta experiences: What did you learn early? What surprised you? What would you do differently?
• AI and Agentforce in practice: Real-world examples, architectural decisions, and lessons learned from designing Agentforce and Salesforce Headless 360 architectures
• Lessons learned through implementation: Real-world decisions, trade-offs, and outcomes from solutions built on Salesforce products, Agentforce, and the Salesforce 360 platform
• Successful implementation and adoption strategies: The architectural decisions, trade-offs, and learnings that made the difference
• Applying the Well-Architected Framework: How-to guides and case studies demonstrating how you’ve applied Well-Architected Framework principles to real-world architecture, design, and implementation challenges
• Cross-cloud architecture: Designs and solutions that span multiple Salesforce clouds, highlighting how the pieces fit together
• Forward-looking designs: Best practices and patterns for designing for what’s next, including the agentic era and next-generation Salesforce architecture

If you’ve done something worth sharing, we want to hear about it.

Follow Salesforce Architecture Blog writing best practices

The Salesforce Architecture Blog is read by architects who are looking for content that helps real world architectural decision making. A strong submission does not just describe what you did, but gives the reader enough of your thinking that they can make a better decision in their own context.

Lead with the architectural story, not the technology

Before you think about writing about a product or capability, ask yourself: what is the architectural story here? What were you navigating? What were the stakes? Technology decisions become meaningful when the reader understands the context in which they were made and the alternatives that were ruled out and why. 

If your post could be summarized as “here is how Feature X works,” it is not ready yet.

Show your thinking, not just your solution

An architect’s value is not in providing a solution, but in being able to justify the rationale. That applies to your writing too. For every decision you describe, explain what you considered, any assumptions you made and what you ruled out. This also means going into the details of the trade-offs, rather than focusing on outcomes alone. 

The reader’s context will not be identical to yours, so they will need enough of your reasoning to adapt to their specific situation. If a section only states conclusions without explaining the conditions under which they hold, expand it to provide insights into the reasoning and what made you go for one approach over another. This way other architects can apply the reasoning to their particular situation. 

Ground it in a real-world context

You do not need to share every detail of the engagement or even the entire architectural landscape. Instead, make your situation specific enough for the reader to be able to orient themselves. “We ruled out Platform Events because the subscriber could not guarantee a processing order” is more useful than “we evaluated several options.” 

A well-chosen scenario or use case anchors the article in a way that generic guidance never can. Concrete yet universally applicable examples are what makes your experience genuinely useful. 

Make your insights transferable

Finally, what are the transferrable or universal lessons that can be learned from your experience? Can you refer to an existing resource on the Architecture Center or did you leverage a pattern that is of use to others? Increasing relevance also includes calling out the conditions that made your approach the right one, and flagging where it would not apply. If your preferred approach requires a capability that is not universally available, tell the reader what to do when they do not have it. 

Tips earn their place when they are specific and grounded. “Test your automation density before choosing a pattern” is a tip. “Ensure proper governance” is not.

Prepare for the submission window 

The submission window will open Monday, June 1, 2026 at 8:00 a.m. PT and will remain open through Friday, June 19, 2026 at 5:00 p.m. PT.

Prepare for your submission by completing the following:

1. Review the Salesforce Architecture Blog: Community Author Program Submission Guide and Blog Template.
2. Write your complete blog draft.
3. Use the AI review prompt in the Submission Guide (Step 1) to review your draft, or apply it to your outline before you start writing.
4. Submit your final draft through the submission form beginning June 1, 2026. The submission form will be added to this page and shared across Salesforce Architects social channels when submissions officially open.

What happens next

Not every submission will be selected for publication. If selected, you’ll work with the Salesforce Architect Relations team through the review and publishing process. Authors will receive an email notification regarding their submission status by July 15, 2026.

Frequently asked questions

• Who can submit?: Anyone external to Salesforce may submit a blog for consideration. We’re looking for architect-focused content that highlights architectural thinking, real-world implementation experience, and actionable insights for the Salesforce Architect Community.
• Can I submit multiple submissions?: You may submit multiple blog entries for consideration. However, we encourage contributors to focus on quality over quantity and ensure each submission aligns with the program goals, content standards, and author guidance.
• Do I need to submit a full draft or just an outline?: We ask contributors to submit a full draft for consideration. This helps us better evaluate the depth, clarity, and relevance of the content during the review process. 
• Can I mention my company, product, or services?: Promotional references of any kind are not permitted. Authors may not promote a company, product, consulting services, or commercial offerings within the blog content.
• Can I submit content that has been published elsewhere?: We are looking for original content intended for publication on the Salesforce Architecture Blog. While similar topics may exist elsewhere, submitted content should not have been previously published on another site or platform.
• If my submission is not selected, can I submit again later?: Not every submission will be selected for publication, and topic priorities may evolve over time. Authors are encouraged to continue refining and submitting future ideas and perspectives for consideration.
• Are AI tools allowed during the writing process?: We encourage authors to use the provided AI review prompt found in the Salesforce Architecture Blog: Community Author Program Submission Guide and Blog Template to help review a blog outline or draft. However, submissions should reflect the author’s own real-world experience and perspective. The program is intended to showcase practical implementation insights, architectural decisions, lessons learned, and patterns that other architects can apply in their day-to-day work.

Additional questions?

Post them in the Salesforce Architects Trailblazer Community Group.

We look forward to seeing the decisions, patterns, and solutions you’ve been working through and how you’ll share them with the Salesforce Architect Community.