Content last updated August 2023.
The Salesforce Architect blog is a tech publication for architects, by architects. We explore and celebrate what matters to architects and demystify the complex roles architects play: leader, builder, designer, planner, creator and problem solver.
Through the content we publish, we create new ways for architects to learn, understand and connect.
You can find our blog on Medium.
Calls for Content
We accept submissions through our call for content cycles.
Our call for content is open until September 30, 2023. We are happy to accept your submissions at this time.
Below is an overview of how submissions work, content we are interested in publishing, and more about how we evaluate submissions.
How to submit your draft
- Write your draft. We can only consider completed blogs. All submissions must use the Architect Blog Template (Quip account required)
- Share your draft. By default, your draft in Quip is visible only to you. In order to consider your submission, you’ll need to give our team access to your draft in Quip. Here’s how:
- In Quip, click the “Share” button in the upper right corner
- Go to the section labeled “Shareable Link”, and toggle the shareable link setting to ON
- Click the “Link Settings” button
- Scroll down to the “Allow access outside of your company” checkbox and select it
- Copy the link URL (you’ll use this in the next step)
- Submit your draft. Fill out our blog intake form, making sure you use the URL from step 2. Note: This form is ONLY open during a call for content. We do not accept or read submissions outside our calls for content.
- Check your email. You will receive an email confirming that we’ve received your submission.
- Celebrate. Your work is done. (For now.)
After the submission window closes, our team will read and review every submission at least twice. You’ll get a decision by email approximately 3 weeks after our call for content closes.
We cannot provide feedback about individual submissions. If your post is accepted for publication, the email will provide next steps.
Things to keep in mind as you write
We value content that is authentic, sharing real-world experiences or information to help inform the decision-making process, and containing resources or guidance readers of our blog can use right away. Here are some of the kinds of content we are most interested in publishing:
Lessons learned on the job
How to and practical advice from experienced, working architects. Explore lessons learned and ways to navigate grey areas in architectural work. Blogs that share real-world experiences matter because:
- Stories of success and failure have equal value
- All architects benefit from learning about diverse, real-world experiences
- Salesforce is often just a piece of an architect’s entire system landscape
New architectural perspectives and frameworks
Help architects gain different ways of thinking and problem solving. Content that shares new & diverse perspectives matters because:
- Technology is a wide spectrum of tools and skills
- Expertise in technical, business, problem solving, and interpersonal skills is essential for architects
- Representation and equality help architects see examples and models of diverse career paths
- Architects learn from other architects most
Some samples from our blog
We publish a variety of blogs. Not every blog falls into the categories above, and we welcome new ideas.
Below are some examples of different blogs that resonated with our readers.
Some tips to help you shape your ideas into a blog draft:
- If you’re writing a ‘how to’ or ‘lessons learned’ style of post:
- Start with a clear, simple explanation of your use case/business scenario
- Illustrate key points with concrete examples (vs. generalized statements)
- Credit authors or sources of any stats, links, articles, terms, etc. you reference
- All diagrams must use our kit of parts (which is also available as a shape library in Lucidchart)
- No selling.
- Focus on ONE big idea. Even if you have an idea for a series, each post should be worth reading on its own. (Plus, we can't accept series submissions at this time--so just write a great first post!)
Some details to double-check (before you submit!) to give us your best possible draft:
- Do you have a good, clear title? Here are some questions to ask, to help you think through your title:
- If I was doing an internet search for answers related to this post, are these words I would use to search?
- If this title was in a list of search results, would I click on it?
- Can I read the title out loud easily?
- Do you have a summary clearly explaining why this matters to architects in less than 200 characters?
- If you are recommending specific resources, did you include links? Are those resources open & freely available for readers to use in their day-to-day work? (We prefer sharing resources that aren’t behind lead capture forms, paywalls, etc.)
- Is your draft around 2,000 words (or less)?
- Have you shared your draft with our team? (See ‘How it Works’ for steps.)
How we consider submissions
Our blog is a tech publication for architects, by architects. We consider every submission on an individual basis, and work to publish a wide variety of content, voices, perspectives. Below, you'll see the criteria we ask our expert readers to use as they consider each submission independently. We also use this criteria in our editorial discussions, as we make final decisions. This is not a checklist for authors to follow. It is a way of understanding what kinds of questions we will ask about each submission we receive.
Reasons for an automatic "No"
There are some factors that may automatically disqualify a draft from further consideration:
- Presenting someone else’s work or ideas without credit
- Trying to sell products or services
- Submitting a blog that’s already been published
- Submitting a draft that isn’t finished
- Not sharing a draft properly in Quip
- Editing a draft after the call for content closes
- Making recommendations that contradict Salesforce Well-Architected
- Submitting content authored by artificial intelligence as if it was your own work (example: ChatGPT)
Guidance for Editorial Consideration
|Topic or Focus Area
Is this about something that is new or emerging?
Is it time-sensitive?
- The topic or subject is new and noteworthy.
- The topic or subject addresses an emerging, real-world context.
- The content brings a new perspective to a common or familiar topic or subject.
- Topic or subject is used superficially or to 'grab' attention, without substance in the content.
- Topic or subject is well documented or discussed elsewhere & this brings no new information.
- Topic or subject is used out of context or in ways that are signficantly misleading.
| Accuracy & practicality
Is the guidance actionable or achievable?
Is it factually supported?
- Content addresses a broadly applicable solution with repeatable steps.
- Content recommends solutions or patterns that will scale.
- Content includes clear artifacts (using our templates).
- Recommendations use products or features in ways that are supported and generally available.
- Content uses anti-patterns or states information that is not backed by other sources (help docs/developer docs/etc).
- Recommendations involve products that are end of life/soon to be deprecated.
- Content addresses obscure or very specific use cases that do not easily translate to broader usage.
|Structure & Readability
||Clarity & focus
Is the purpose of the content clear?
Does the content stay focused on the topic?
- The purpose of the content is stated at the beginning and is delivered by the end.
- The flow between concepts is clear & supports the intent of the content.
- There is no clear purpose stated in the beginning of the content OR the content does not meet the proposed outline.
- The flow between concepts is not clear & is distracting to a reader.
- The content doesn't stray from the topic or have chunks of 'filler' or unrelated content.
Is there genuine value for a reader?
Is this content worth a reader's time?
- The content provides genuine value for an architect practitioner
- Each section of the content provides useful detail, real-world examples and/or resources to help a reader understand the topic.
- Each section of the content helps illustrate the main topic. Any humor, stories or examples are helpful to explaining the topic.
- The content is largely superficial or full of generic statements. There is no real-world use case presented with credible detail.
- The content uses hyperbole to try establish relevance, without supporting facts.
- The content uses imprecise language and/or language that is distracting and makes it harder to understand the actual topic.
- If used, humor or stories or examples are distracting or hard to relate back to the main topic.
|Visuals & artifacts
- Visuals, artifacts, illustrations are accurate and clear.
- Where applicable, our templates and styles are used.
- If relevant templates or styles are missing, the main value of the content isn't the visuals or artifacts.
- Visuals, artifacts, illustrations are distracting or unclear (or subject to copyright).
- Visuals or artifacts should have used our styles or templates, and the main value of the content is the visuals or artifacts.
|Transparency & Integrity
Is this the author’s own work or experience?
Are they sharing someone else’s concept or tool?
Are attribution and intellectual property clear?
- It is clear the author is sharing their own experience or work.
- If the author shares someone else's concept or tool, attribution is clear.
- Resources or tools are not blocked by a paywall and/or lead capture forms.
- Stats and numbers have clear attribution.
- It is unclear if the author has permission to share examples, tools or resources.
- Attribution for concepts or stats is unclear.
- Resources or tools are blocked or not generally available.