Today we released new features and content to the Well-Architected Framework and the Pattern & Anti-Pattern Explorer 🎉. These new enhancements, while small, are a first step in a larger effort to bring Data Cloud and Einstein into the Well-Architected Framework and to enhance the usability of our tools. Here’s a look at what’s new.

Well-Architected Guidance for Data Cloud & Einstein

We finally have guidance for Data Cloud & Einstein in Salesforce Well-Architected. This is a big milestone for us, because it is the first time we’re publishing guidance that Salesforce can stand behind for these new innovations. We stand behind this guidance thanks to a cross-functional group of experts from our engineering, product, professional services and pre-sales organizations who came together to identify, debate, and discuss what patterns our customer architects should follow (and the anti-patterns they should avoid) when designing solutions with CRM, Data Cloud and Einstein.

You’ll be able to find this new content by navigating to the Pattern & Anti-Pattern Explorer where you can filter for the Location of either Data Cloud or Generative AI.

The group of experts who helped with this release will continue to identify new guidance and iterate on our backlog of guidance for publication on architect.salesforce.com leading up to Dreamforce.

Usability Enhancements for the Pattern & Anti-Pattern Explorer

As we continue to build out our library of patterns & anti-patterns, being able to find the guidance you need fast is more important than ever. We heard your feedback about the usability of the Pattern/Anti-Pattern Explorer, and that you wanted to search across the entire Framework without knowing what part of the Framework taxonomy the guidance is stored in. That’s why we adjusted the filter behavior of the Explorer. Now you can search for patterns & anti-patterns without first selecting a Framework dimension.

July 2024 Release Contributors

Thank you so much to our content contributors and technical reviewers:

• Ahmed Keshk
• Andres Perez
• Arturo Alvarado
• Arvind Raman
• Bret Brizzee
• CJ Buskey
• Gina Nichols
• Jim Stukas
• Jordan Seeley
• Justin Piehowski
• Marc Braga
• Marissa Chesney
• Matt Dykeman
• Michael DePuy
• Moustafa Ishak Kamal Moustafa
• Patrick Hermiller
• Scott Robbins
• Shoby Abdi
• Stella Hang
• Susannah Plaisted
• Tom Leddy
• Zayne Turner

Tell Us What You Think

We can’t wait to here what you think about the latest changes! Help us keep Salesforce Well-Architected relevant to you; take our survey to provide feedback on this content and tell us what you’d like to see next.

July 2024 Well-Architected Framework Release was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

In January we have some new blogs in store for you about Calculated Insights and near real-time orchestration. We also have some great video content planned where we’ll be discussing how architects in the field use Well-Architected.

Our Call for Content is closed through January, but now is the perfect time to think about your future blog posts and to review our submission guidelines.

Let’s take a quick look at some of what you can expect in January.

On the Blog:

• Using Calculated Insights with Hierarchical Data — No matter what industry you are working in, you likely have valuable hierarchical data to work with. Calculated Insights are a great way to unlock the value of this data in Data Cloud. In this blog you’ll learn how to get started with Calculated Insights for hierarchical data, directly from the experts.
• Powering Near Real-Time Orchestration — With the massive amount of data needed to power AI, the Salesforce Eventing team is releasing new capabilities that will reduce data sync times when streaming data from Core CRM to Data Cloud. Learn more about these exciting enhancements.

On architect.salesforce.com:

• We’ll be publishing updates to two Decision Guides: Architect’s Guide to Data Integration and Architect’s Guide to Event-Driven Architecture.

On YouTube:

• From the Field: Designing Intentional Solutions — Susannah Plaisted interviews Well-Architected Ambassador Brian Shea to discuss how he uses the Well-Architected framework deliver intentional solutions for his customers.

On LinkedIn and Twitter/X:

• Two new content shorts highlighting event-driven architecture anti-patterns and considerations for choosing the right data integration tool.

What You Can Do Now:

• Catch up on our December blog posts, including Three Ways Graphs Power AI, Six Steps to Establish a Security Governance Model, and Announcing Salesforce Scale Test.
• Watch our latest YouTube video to get up to speed on how Salesforce’s new vector database will impact the platform.
• Check out the newly released Well-Architected Pattern & Anti-Pattern Explorer and give us your feedback.
• Follow us on LinkedIn and X to make sure you don’t miss our quick takes

January 2024 Sneak Peek was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re like me, you might not have thought very deeply about graphs in quite awhile. But graphs should be back on your radar because of the way they can be used to enhance machine learning. Read on to learn what capabilities graphs bring to the field of AI.

Why use graphs?

Every graph from the most basic to the more complex is made up of two things. Nodes (also known as vertices or points) and edges (or lines). The node is one of the data points or objects on the graph and the edge is the connection between it and another data point or object.

Graphs have been around since the 18th century, when Swiss mathematician Leonard Euler solved the Seven Bridges of Königsberg problem using one of the earliest known examples of graph theory. So why are they such a big deal right now when it comes to AI? Let’s take three examples:

1. Knowledge graphs for storing relationships

A knowledge graph, also known as a semantic network, represents a network of real-world entities — i.e. objects, events, situations, or concepts — and illustrates the relationship between them. This information is usually stored in a graph database and visualized as a graph structure, prompting the term knowledge “graph.” — IBM

Said simply, a knowledge graph represents the meaning of relationships between two objects. In a knowledge graph, the nodes represent entities (like people places, or events) and the edges represent the relationship between those entities. What makes knowledge graphs extra special is that they use a third element, often referred to as a predicate or an edge label, that describes the nature of the relationship.

Let’s take an example. If I were trying to represent that “Susannah works at Salesforce” in my knowledge graph there would be a node for me, and a node for Salesforce. They would be connected by an edge with the property of works at.

This type of graph provides a semantic structure to data. And having an efficient way for machines to ingest and model semantics, or the meaning of a words, is incredibly important to getting good responses from AI.

Complex knowledge graphs can be ingested by an AI application through natural language processing and then can be used as a really fast way to deliver responses to prompts in a generative AI use case or event to enhance predictive AI models like recommendation engines.

For our next example of how graphs can power AI, let’s focus on Data Graphs.

2. Data graphs for storing and retrieving at AI scale

So far we’ve been focusing graphs are really good at storing complex relationships. But graphs can also be an extremely efficient way to retrieve data, especially when you need to run real-time query on extremely large data volumes. Which makes Graphs the perfect tool to use in Data Cloud.

In Data Cloud there’s a concept called a Data Graph. A Data Graph is an object that stores the data lakehouse objects as nodes and the relationships between those objects as edges. From the Data Cloud UI, you could take several Data Model Objects (DMOs) that contain the Unified Individual, their purchase history, and their browsing history and generate a new Data Graph that takes the data from all three DMOs and transforms the hierarchical relationships between these relationships into a single flattened Data Graph record that contains both the metadata structure and its related data stored as a JSON object.

The Data Graph can be used for a graphical representation, but the real power is that this Data Graph is an additional “relationship” layer that sits on top of our data lakehouse. We can improve query processing time because we’ve offloaded some of the computations that would need to happen if we were to query the database directly. This is incredibly important when it comes to AI use cases where users will expect real-time responses that depend on querying across huge sets of data.

For the third and final example let’s discuss how to ground a prompt with a graph.

3. Graphs for better generative AI responses

Let’s stay with our Salesforce Data Graph for a moment. Data Cloud and Prompt Studio are both built on Salesforce, and when they are used together, they can help improve responses generated through the Einstein Generative AI Trust Layer. In coming releases, you will be able to take a Data Graph from Data Cloud and use it in Prompt Studio.

In practice, you will write your prompt in Prompt Studio, then select a Data Graph (represented as denormalized JSON) to be sent to the LLM as additional context. The LLM will then take the prompt and the data graph we sent to generate a better response, using a process called retrieval augmented generation or RAG.

Because our data graph is a denormalized JSON object we are able to send lots of related data from across multiple objects in data cloud along with our prompt. This is going to allow the LLM give a better response that takes into account a customer’s purchase history, maybe their browsing data or even an organization’s knowledge base even though they aren’t a part of the original prompt and the LLM has never been trained with any of the data graph data.

Conclusion

I hope these three examples have helped illustrate why you should care about graphs when it comes to AI and Salesforce and how different types of graphs can be used to do some pretty cool things in machine learning. Salesforce will be leveraging the techniques you just read about as it builds out its AI capabilities.

In fact one of the newest AI pilot features, Einstein Search Answers uses data graphs and retrieval augmented generation. And next year, you’ll be able to use Data Cloud’s data graphs to enhance your prompts. To explore more upcoming product innovations visit the Salesforce Roadmap Explorer on architect.salesforce.com.

References

• An Introduction to Knowledge Graphs
• What is a knowledge graph?
• What is retrieval-augmented generation?

Three Ways Graphs Power AI was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

If I were to do a traditional web search for “Astro”, one of the Salesforce mascots, I’d get some results that are useful. But I’d likely also get some unrelated results like:

• Astronomy
• Houston Astros baseball team
• American Society for Radiation Oncology (ASTRO)

That’s because search engines have historically been driven by keyword, or lexical, search. The search engine serves up relevant web pages by giving me the literal matches of the words I type into the search bar.

What is semantic search?

To understand semantic search let’s first start with what the word semantics means.

se·man·tics

/səˈman(t)iks/

noun

the meaning of a word, phrase, sentence, or text.

So semantic search means searching by meaning instead of searching by something else, like a keyword. If we take our example from above and utilize semantic search instead of lexical search, I might get back additional search results for other Salesforce characters like:

• Cloudy
• Codey
• Ruth

This is because semantic search uses meaning, or context, to find matches. These results might not match the literal search term I typed in, but they match the intent of my search. But how does this work? How does a search engine, or a machine for that matter, understand meaning?

How machines interpret meaning

For many years technologists have been using the methods like semantic HTML and intent tables to label and store data needed to generate more meaningful search results. But this, for the most part, this has required human interaction, because humans are the ones who understand the meaning behind the words we choose.

But in machine learning there is a concept called vector embeddings. Vector embeddings are an essential part of how new generative AI tools like ChatGPT work. Stay with me on this one, GPT stands for generative pre-trained transformer. The “transformer” part of GPT refers to the process of encoding and decoding things that humans can understand like language or visuals, into a format that a machine can understand.

One of the formats a machine can understand is a vector embedding. Vector embeddings are essentially lists of numbers that represents the original text, image, audio, or video. Now this is where it gets really cool.

As previously stated, a vector embedding is a series of numbers, but these aren’t just any numbers. They’re coordinates for how the original object (the text, image, audio etc) is represented by the system. If this is hard to visualize, imagine the old school dewey decimal system in the library where books with similar characteristics are grouped together by classification.

You use this single set of numbers to find the location of the book you’re looking for. Coordinates on a map use two dimensions to locate your destination.

A similar mental model can be applied to get a basic understanding of vector embeddings. While our simple examples above use one or two dimensions, the vector representation used in natural language processing can have thousands of dimensions.

At a very high level, here’s how an object that a human can understand is transformed into a format that a machine can understand. The object is fed through an embedding model (such as T5 or BERT for example). This model does the heavy lifting of encoding our original object to an embedding (an array of numbers).

Then, using some pretty fancy mathematical functions like cosine similarity, these embeddings can be plotted on a vector (an arrow with a length and a direction, as pictured below). Objects with similar meaning get plotted near each other in vector space. As a result, a machine can use the angle and distance between vector embeddings as a proxy for the semantics (or the meaning) of a piece of text, image or audio.

Conclusion

Back to our original scenario of searching for the Salesforce character Astro. If Astro was translated to a vector embedding, his coordinates would be in the same vector space as Codey, Cloudy and Ruth so our semantic search would return our entire crew of Salesforce characters.

With the rise of generative AI, understanding how semantic search works is important because it is going to transform the way we search for information. It will also change the way we interact with applications like Salesforce. In fact one of Salesforce’s newest AI pilot features, Einstein Search Answers, is powered by semantic search and vector embeddings. To explore more upcoming product innovations visit the Salesforce Roadmap Explorer on architect.salesforce.com.

For the press release on Salesforce’s new Vector Database built on Data Cloud visit: https://www.salesforce.com/news/press-releases/2023/12/14/unstructured-data-ai-search-einstein/

References

Towards More Intelligent Search: Deep Learning for Query Semantics
Semantic Search with Embeddings: Index Anything
A Comprehensive Overview of Transformer-Based Models: Encoders, Decoders, and More
What are Vector Embeddings
Meet AI’s Multitool: Vector Embeddings
Salesforce Roadmap Explorer

What is Semantic Search? was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

Susannah: What diagrams do you use over and over in a project?
Melissa: System landscape and user journey map, definitely.
Johann: User journey map, business capability map and system landscape.

Susannah: Can you give us a quick definition of a user journey map?
Melissa: A user journey map is a visual representation of a user’s interactions and experiences with a product, service, or system over time.

Susannah: Why is this a diagram you can’t live without?
Melissa: Creating a user journey map at the beginning of a project is crucial because it helps you understand the customers needs and pain points. It’s also a great way to scope a project and this artifact can be used to get alignment with the entire team.
Johann: I agree, every solution has to be built for the user. A user journey map helps me understand the steps and actions a user takes to reach their goal.
Susannah: Before we go any further, I should note that we started our conversation here, there isn’t one “correct” order to create these diagrams in. If you’re working on a project that’s already scoped then a journey map is a great place to start. But if you’re an enterprise architect working on an overall business transformation you might start with the capability map, then go to a system landscape to assess your current state.

Susannah: What stakeholders should be involved when creating a user journey map?
Melissa: All journey maps start by mapping out the steps involved in delivering value to a customer. Any stakeholder involved in those steps should be involved.
Johann: Stakeholders for your journey map will span multiple teams. Creating this diagram is a great way to bring together stakeholders that don’t usually talk to each other!

Susannah: Are there any things that architects should avoid when starting a user journey map?
Johann: Keep it simple! It’s easy to get overwhelmed by all the templates and possibilities. Putting down the phases and actions of a User for a given scenario is already a great step forward.

Susannah: What diagramming tool do you use for your user journey maps?
Melissa: I often find myself drawing it freehand on a whiteboard or on paper.
Johann: I have been using PowerPoint so far but I am currently practicing my Lucidchart skills.

Susannah: Funny you should say that, I was just experimenting with a user journey map using the Salesforce Diagramming Framework.

Melissa: Nice!
Johann: That looks like a great starting point, maybe it can be added to the Template Gallery? 😉

Susannah: I’ll work on that! 😄 OK, next you mentioned the business capability map. Why should architects be creating these?
Johann: IT Architecture is a service function by definition. We help business do their job using software. A business capability map is the first step of understanding what the entire organization needs. It helps to identify gaps and overlaps.
Melissa: A business capability map is a valuable tool used at the beginning of a project because it helps align the team around what matters. By mapping out the business drivers, you can ensure that the project’s scope and goals are in line with what the organization needs to achieve.

Susannah: Do you have a template you like to use for your business capability maps?
Johann: I start by using the business capability map template on architect.salesforce.com, I start by customizing simple things like adding the customers logo and business drivers.

Susannah: I like that approach, then you could have a working session to start filling it out.
Johann: Exactly! You’ll want to bring together cross-functional business leadership and subject matter experts (SMEs) for each business driver. You’ll also need stakeholders from IT who can map out the high-level product positioning.

Susannah: Any tips you’ve found for building great capability maps?
Johann: I have to stop thinking like a Salesforce architect but like a business architect. A business capability map is the what and not the how.
Susannah: Yes, it’s important to remember that this diagram is not about implementation. It’s the “art of the possible”.

Susannah: Do you keep these updated throughout the life of a project?
Melissa: Yes. Also, beyond the immediate project, a capability map can be used for long-term planning. It helps the organization understand where it wants to go and what capabilities it needs to develop or enhance to stay competitive.

Susannah: Last but not least, we have the system landscape, a level 1 documentation and implementation diagram. What should we know about system landscapes?
Melissa: A system landscape is a visual representation of the various systems, components, and their interactions within an organization’s IT environment. Creating this diagram allows me to understand the current state of the IT infrastructure and identify dependencies.
Johann: The system landscape is at the center of my delivery. A Salesforce implementation is never alone but always part of a larger landscape. To build a solid system landscape you’ll need to work with IT stakeholders across your enterprise so you can identify and gather appropriate details on the systems connected to Salesforce. This is crucial for project success.

Susannah: What value do your customers get from the system landscape?
Melissa: A system landscape diagram helps my technical teams identify dependencies between different systems and components. This is critical for assessing the potential impact of changes or enhancements to one system on others. It helps in managing and mitigating risk.
Johann: Often times, the customer is surprised themselves about the number and complexity of interactions between systems to make a business process work in Salesforce. Every integration, every adoption or even just retirement of a system must be part of architecture, scoping, planing and risk management.

Susannah: What is one common pitfall you see architects make when designing a system landscape?
Melissa: Architects often go too deep but not wide enough. System landscape is not the place to discuss specific integrations but to talk about stay on a high level. Furthermore, it’s really easy to forget or ignore systems.

Susannah: Can you share an example system landscape you can share with us?
Melissa: I like to use the system landscape diagram on the Salesforce Architects website as a starting point.

Susannah: Any final advice for architects looking to build great diagrams for new or existing implementations?
Melissa: The three diagrams we covered should all be included at the beginning of any project. Starting with these diagrams will help improve the success of your project overall.
Johann: The first, keep it simple! Regularly I feel overwhelmed by all the diagrams, templates and details. It’s better to have a clear and simple diagram than no diagram at all. And secondly, practice, practice, practice! As kids we learn reading and writing by starting small and working our way up. I like to do the same for my diagrams, practice on small examples. Don’t wait for your next big project to create all these diagrams. Head to your diagramming tool of choice and start experimenting. This way you are ready when the time comes.

Interested in learning more? Explore the Diagramming Framework resources on architect.salesforce.com.

About the Authors

Johann Furmann has a career that spans consulting, product management and architecture. During the last several years, Johan has spent his time between coaching future Certified Technical Architects (CTAs), developing AppExchange products and architecting Salesforce solutions.

Susannah Plaisted is an Architect Evangelist at Salesforce. She is passionate about empowering and inspiring Architects and ensuring they have the tools and skills they need to build better solutions.

Melissa Shepard is a Certified Technical Architect,, 35x Salesforce certified, Managing Director & Co-Founder of Estarei a Salesforce Consulting Partner, founder of ScaleUp Archs & Architect Ohana Slack, Mulesoft Ambassador, Marketing Champion and is an organizer for multiple Dreamin’ events.

Three Diagrams Architects Can’t Live Without was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

Susannah: Most folks who’ve been around Salesforce for awhile know that Named Credentials are not new.
Ross: Exactly, Named Credentials have been part of the Salesforce platform for more than a decade.

Susannah: But in case anyone needs to catch up, when we talk about Named Credentials we’re referring to the features that handle authentication for outbound integrations. With Named Credentials you define the endpoint and its authentication details declaratively. Then behind the scenes, Salesforce handles the heavy lifting of the authentication protocol implementation and endpoint allowlisting (among other things).

Using Named Credentials is pattern all architects should be utilizing instead of trying to handle authentication details in your Apex code. But lately things have been changing with Named Credentials. Ross, what should architects know about these changes?

Ross: In the last few years, we’ve revamped the architecture underneath Named Credentials to expand what’s possible and prepare for future growth. This expanded infrastructure is focused around two new ideas.

Susannah: OK, what should architects focus on first?

Ross: The first thing to know is that authentication is now separated from the endpoint definition. Separating them allows the same authentication configuration to be used for multiple endpoints.

For example, you might authenticate against Google’s OAuth service, and then make calls to both the Google Drive API and the Google Calendar API. The endpoint is still defined via the Named Credential object, but now it has a lookup to something called an External Credential.

Susannah: External Credentials, that’s new to me. How are they different from Named Credentials?
Ross: The External Credential captures the authentication details, and the Named Credential holds the endpoint. The two are separate, but they work together.

The connection between a Named Credential and an External Credential is a straightforward lookup, similar to how a Contact is related to an Account. You can view the External Credential and see all the associated Named Credentials in a related list. And just like with Accounts and Contacts, you’ll want to create the External Credential first, and then create the Named Credential that looks up to it.

Susannah: You mentioned two new ideas that went into the revamped Named Credential architecture. What is the second?
Ross: Secondly, permissions are now explicit instead of implicit.

Users now need explicit permission to make callouts with a given set of credentials. This extends to ISVs as well. If a managed package needs to make a callout using a Named Credential created by an administrator in the org, that package’s namespace needs to be allowlisted on the credential.

Susannah: Anything else notable about the changes to the architecture?
Ross: The Named Credential object now has a Type field that functions like a Record Type designation. Newer credentials will be reflected with the Type of Secured Endpoint, and in the list view you can see both the Type and the associated External Credential.

The original iteration of Named Credentials is reflected with the Type of Legacy. Legacy credentials store all settings on a single setup object. Older credentials don’t have a lookup to an External Credential. Here’s what it looks like in Setup in Lightning:

Susannah: How can people get started with External Credentials?
Ross: Some people think they have to “switch” from Named Credentials to External Credentials, but that’s not true. They’re used together and it’s available in Setup today. You’ll create both, and link them together. The Named Credential object is still critical, not least because it still is referenced by Apex code that uses that credential in a callout. We don’t want to change how people write Apex code or build Flows.

Susannah: OK, that makes sense. But what about the explicit permissions you mentioned earlier?
Ross: Users now need permissions to make callouts using specific credentials. It’s similar to how we added the requirement a few years ago that users need explicit permission to run an Apex class. A key principle for us at Salesforce is that everything is secure by default.

Susannah: I know that one of the reasons your team made these changes to the architecture is to continue to invest and advance capabilities around trust. Walk us through how we can use these changes with Named Credentials to build more secure integrations.
Ross: When creating an External Credential, you now also create one or more Principals underneath it, each reflecting the identity of the caller in the external system. AWS also uses the term Principal to represent the same idea. Many times, this identity is an “integration user” or “service account” that does not correspond to an individual human being. Principals like that typically hold an API key or other secret. The permissions make it explicit that a given User has been granted access to that key or secret, not in its raw form, but within the context of a callout. The callout will be blocked if the calling user hasn’t been granted permissions to the Principal.

You’ll see External Credential Principal Access as a new option available when configuring a Permission Set. You could also associate this with a Profile, but the best practice is to use Permission Sets and Permission Set Groups. Developers can also manage access by creating SetupEntityAccess records directly via Apex code.

Susannah: You mentioned you can create one or more Principals. When would you need multiple Principals?
Ross: Sales Cloud users could have different access than Service Cloud users, for example. Or perhaps Service Cloud agents have a read access to data in a remote system, but Service Cloud managers also have the ability to read and delete records in that external app.

If a single User is granted access to multiple Principals for the same External Credential, there’s a precedence that can be applied to decide which set of credentials to use. Essentially, admins set a numerical order using a Sequence Number. Multiple principals is a key capability enabled by our updated architecture, and large enterprises with tight access controls for different departments should consider implementing them.

Susannah: This varied level of access reminds me of record sharing in Salesforce.
Ross: Yes, this can enable similar outcomes. Most external systems do not have access controls that are as robust as what we offer around record sharing in Salesforce. Typically, these apps provide some way to define broader roles like “Sales” or “Marketing,” which are often sufficient for integration use cases. Our goal is to enable access that’s as fine-grained as the external system allows.

Susannah: Speaking of the external system, do you have any guidance for architects when integrating with an external application that does support fine-grained access controls?
Ross: Hyperscale providers like AWS do in fact offer very fine-grained access controls, and we encourage customers to take advantage of them to the fullest extent possible. That way, the Salesforce “client app” has minimal, optimized access to the remote system. We enable this via support for AWS’s IAM Roles Anywhere, dynamic scopes in OAuth (which is great for Snowflake), and more. OAuth also offers a path for individual users to have their own auth/access to the remote system, but coarse-grain access (e.g. roles) in external systems is more common.

Susannah: Is there anything else to know about permissions and the new Named Credentials architecture?
Ross: Yes. Users who make callouts will also need access to a new standard object called User External Credentials. This object holds the actual encrypted access tokens or other secret values used to call out the external system. The new architecture stores these values in a data object so that many thousands of them can be persisted in a robust way, and we sidestep security concerns by separating them from metadata (which is exported from orgs in plain text).

Here’s a diagram that illustrates how it all fits together:

[Alt text: A diagram illustrating the new Named Credentials paradigm]

Susannah: OK, we’ve spent a good deal of time talking mechanics, but let’s walk through a real life example of how the Named Principal and User External Credentials are utilized in a system-to-system integration.
Ross: Great idea. While I’m sure you’ve performed the “OAuth handshake” many times to grant one system access to another on your behalf, most integrations are not configured in a way that requires end users to take action. System-to-system integrations are more often configured by administrators directly, and one system is given a means to programmatically “log into” the other. This can be done via certificates, API keys, or other shared secrets (e.g. passwords).

In scenarios like this, a Named Principal is used by multiple Salesforce Users to share the same credentials. When this occurs, you’ll likely be in a situation where all those Users need Modify All permissions to the User External Credentials object. Imagine that User A is first to establish a connection with an external system and obtains an access token. After some time, the token expires. Then, User B uses the same integration, and their activity prompts Salesforce to refresh the token. When the new token is persisted, it overwrites a value in a record created by User A — hence the need for Modify All.

And even though Users have Modify All permissions, they can’t directly view or change the values from the UI, SOQL, or Apex. That access is only used internally when tokens need to be managed.

Susannah: Any other new features that architects should be aware of?
Ross: To facilitate the system-to-system integrations I mentioned earlier, we delivered support for some popular authentication mechanisms: Client Credentials and the JWT Bearer Flow in OAuth, custom claims in JWT authentication, and API keys.

You may recognize the terms Client Credentials and JWT Bearer Flow. Administrators leverage these approaches to enable integrations where an external app needs to call into Salesforce. Now, they can also be used when Salesforce needs to call out to a service running on a hyperscale public cloud like GCP. Since it’s quite common for large vendors to recommend either Client Credentials or the JWT Bearer Flow, we wanted our customers to be able to meet this requirement without writing code.

API keys are relatively simplistic, but also very commonly used. We give you the ability to store the keys in an encrypted manner and attach them to your callouts in the header. You can even use formulas to manipulate the header’s value, further reducing the need to use code to manage authentication. Keeping secrets out of your code is key to maintaining compliance with standards like SOC II Type 2.

A quick note on JWT: technically, the JWT Bearer Flow is different from what we simply call the JWT authentication protocol because the former is part of the OAuth spec. Both use certificates to sign the JWT and increase security, making them an attractive choice. Use whichever one is supported by the external system in question.

Client Credentials, in contrast, uses a Client ID and Secret to identify Salesforce as the “client” application. The ID and Secret function similarly to a simple username and password, so manage those carefully and plan to rotate them occasionally.

Susannah: What’s the best practice for rotating keys?
Ross: This is a great segue into the last major topic we haven’t yet touched on: our configuration API, available in both Apex and via REST (where it’s referred to as the Connect API). You can use this API as a control plane to create and manage credentials, enabling what you might call infrastructure-as-code or policy-as-code.

Susannah: Some architects might be wondering, why not just use the Metadata API to manage my credential setup programmatically?
Ross: While Named Credentials do support the Metadata API, this can only be used to move some configurations between orgs. Unfortunately, you can’t use it move any shared secrets like API keys between your orgs, because that would involve retrieving the secret value from the org in plain text (before deploying it to the target org). You also can’t package these secrets, for the same basic reason. This new configuration API gives you different options to solve that issue, and others we haven’t foreseen regarding setup. You can write code against this new API and blend it into your CI/CD pipeline.

Susannah: Pretty cool. Any closing thoughts?
Ross: We expect some ISVs to extend their existing custom setup UIs to automate the administrative burden around creating credentials. It’s frustrating when the ISV can predict what the configuration should be, but can’t package the credentials to reduce the setup hassles experienced by our joint customers.

To address this, we made the new configuration API accessible from Apex. Managed package code can create credentials on behalf of the administrator, and all they have to do is flip a toggle switch to enable them for callouts. The ISV can build a UI that matches their brand and unique needs.

We want all our customers and partners to benefit from these new features. Our vision is that you can enable integrations without writing code to manage authentication. Please reach out in the Trailblazer Community and IdeaExchange to engage with us and let us know how it’s working for you and your team!

Conclusion

I hope that this conversation has has provided insight into some of the exciting enhancements available to secure outbound integrations. Security is the first priority when it comes to building Well-Architected Salesforce solutions, which is why it’s so important for architects to be aware of the latest changes to the platform. Interested in learning more about building secure solutions? Check out the extended conversation I had with Ross below, and explore the Well-Architected-Secure whitepaper to learn even more about organizational, session, and data security.

About the Authors

Ross Belmont is a Director of Product Management covering Platform Data Services. He has more than a decade of experience with the Salesforce ecosystem.

Susannah Plaisted is an Architect Evangelist at Salesforce. She is passionate about empowering and inspiring Architects and ensuring they have the tools and skills they need to build better solutions.

What’s New with Named Credentials was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

In November we’ll be publishing new blogs with automation best practices, tips for composable solution design, and new patterns for generative AI. There will be enhancements to our website and fresh video content published all month long.

Speaking of content, our Call for Content will be open so put those final tweaks on your blog. Review our submission guidelines for your best shot at becoming a Salesforce Architect’s blog author in the new year! 🎉 ✅

But we’re not quite done with 2023 yet. Let’s take a quick look at some of what you can expect in November.

On the Blog:

• Building Flows for the Guest User Profile — Unauthenticated guest users shouldn’t have direct access to your protected resources in Salesforce. But what if you need to deliver a multi-screen workflow or wizard for this type of external user? Learn Flow best practices for Experience Cloud guest users that follow the principle of least privilege.
• Use Calculated Insights with Hierarchical Data — Hierarchical data, with its tree-like structure and parent-child relationships has a variety of use cases. Learn how to ingest hierarchical data into Data Cloud and use it to create Calculated Insights.
• Why Graphs Matter for Salesforce Architects — Graphs make it easy to understand data and the relationships between data elements. With the rise of generative AI, knowledge graphs have emerged as a way to organize data in a way that is more flexible and efficient than a database table. Learn why knowledge graphs are key to good semantic search and how you can use a graph to build a better prompt template.
• Composable Solution Design — Architects should set out to create a composable solution design, otherwise it will become more difficult to refactor your solution and introduce composability later. Learn how to adopt a mindset of composability, anti-patterns to avoid, and ready-to-use best practices that will ensure your solution can handle change gracefully.

On architect.salesforce.com:

• Salesforce Diagrams Kit of Parts Version 2.0 — The new icons announced at Dreamforce ’23 will be available in Google Slides and Powerpoint templates in the Diagram Kit of Parts.
• Salesforce Diagram Framework — We’ll be adding Diagram Levels as a filter to the Template Gallery to help you find the diagrams you need faster.
• Design Patterns Templates — Templates are coming to the Design Patterns gallery so you can open them in your tool of choice and get to work. You’ll also be able to search and filter them since the library will be growing.
• Data Models — We are adding several new data models and updates including changes to the Advanced Therapy Management data model for Health Cloud.

On YouTube:

• Under the Hood: Data Cloud & The Event Bus Runtime — Did you know that Data Cloud leverages the Salesforce Event Bus runtime? Learn how enhancements to our new products result in quality of life improvements for our existing services.
• Well-Architected Insights: Intentionality — How are architects in the field using Well-Architected? Learn how one architect approaches building intentional solutions that deliver value immediately and over time.

On LinkedIn and Twitter/X:

• We’ll be dropping tips for architecting healthy multi-org Marketing Cloud implementations this month. Follow us on social so you don’t miss out!

What You Can Do Now:

• Subscribe to the Salesforce Architect’s Youtube channel…we’re almost at 10K subs! 🙌
• Stay up-to-date with our RSS feeds, now available under the Connect tab of our website.
• Find tools and resources for every project phase in our AI Project Resource Gallery.
• Follow us on LinkedIn and X to make sure you don’t miss our quick takes.
• Catch up on our October blog posts, including Delivering Business Value with Customer Journey Maps and 5 Things Architects Should Know About Einstein.

November 2023 Sneak Peek was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Einstein is hyper-focused on Trust

Salesforce’s first core value is Trust. And with all the unknowns about this new technology, trust is at the forefront of the Einstein 1 Platform. The Einstein Trust Layer is a variety of apps and services that support trusted generative AI. From content moderation, to masking personally identifiable information (PII), our generative AI stack, hosted on Hyperforce, allows you to leverage generative AI without leaving the Salesforce infrastructure that you’ve already vetted with your security teams.

Einstein also supports the use of external models that have agreed to a zero retention policy. These external models, like Open AI, exist in a shared trust boundary. This means that your data is not retained by the third-party Large Language Model (LLM) providers and is not used to train their models. If you’ve already built your own LLM, you’ll soon be able to register it in Model Builder using Data Cloud’s Bring Your Own Model (BYOM) capability.

How can you trust that generative AI is bringing value to your business? We’ll soon be providing functionality that will allow you to measure how generative AI is being leveraged by your users. The feedback your users give when interacting with generative AI, like giving a response a thumbs up or thumbs down, will be stored in Data Cloud so you can run analytics to see the performance of your prompts.

2. Data Cloud is a crucial part of the Einstein 1 Platform

To be successful with generative AI, you need good data. The better your data is, the more useful the response from the LLM will be. This is probably not the first time you’ve heard this, but let’s unpack why good data is so important in generative AI.

In order for a prompt to generate a useful response with the business context your users expect, it needs to be grounded. Grounding is the process of enriching a prompt with data that’s specific to your company. This can be done by either adding the additional context directly to the prompt text itself or through a process called retrieval augmented generation. But how will the prompt get the data it needs when your data exists across multiple systems, is extremely large in volume, or is structured in a way that can’t be easily stored in a database table?

All of our generative AI capabilities are built using the Data Cloud infrastructure on Hyperforce.

This means that you can leverage the strengths of Data Cloud to ingest petabyte scale data, work with structured and unstructured data across disparate systems, and create data graphs so that you can retrieve the data you need to generate useful responses from an LLM. The fact that Data Cloud is a crucial part of the Einstein 1 Platform is a key differentiator of Salesforce’s artificial intelligence offerings.

3. Einstein supports multiple models and it’s multi-modal

The Generative AI Gateway, a key part of the Einstein Trust Layer, supports multiple models. You might leverage a Salesforce Hosted LLM like CodeGen, Anthropic or Cohere, or an LLM that has established Shared Trust with Salesforce (like OpenAI). Has your company developed a custom LLM? In the future, you’ll be able to connect it to Salesforce with our Bring Your Own Model (BYOM) capability.

Supporting multiple models is a core tenant of our approach to AI. It allows you to continue to use best-in-breed models that are evolving rapidly. In the short term this means that you’ll be able to choose the LLM you want when you build a prompt template in Prompt Studio.

Our approach to generative AI also allows customers to be multi-modal. Einstein doesn’t just support one modality of content generation. With Einstein you can generate text for an email or service response, generate code with Einstein for Developers, or even generate configuration in tools like Flow Builder.

All of this becomes even more relevant as we prepare for autonomous agents, the next wave of AI. Autonomous agents leverage LLMs, not to predict the next word in a sequence, but to orchestrate business tasks by determining the next best action. What will this look like in Salesforce? Soon you’ll be able to interact with Einstein Copilot, an AI agent that you’ll interact with using natural language. When you “converse” with Einstein Copilot it will identify what business goal you’re trying to achieve. As long as you’ve declaratively “trained” the agent on the type of tasks you need to reach your goal, the AI will orchestrate the work across multiple modalities.

And because we keep trust at the forefront, Einstein Copilot isn’t fully autonomous, there will still be a human in the loop. To go deeper on how autonomous AI could impact the way we build systems I recommend exploring this blog by Silvio Savarese, EVP and Chief Scientist of Salesforce Research.

4. Einstein will change the way we think about application lifecycle management

As architects, we are used to running unit tests with deterministic results. When a Flow or Apex code runs we expect a predictable result. But generative AI is non-deterministic, which means that the response that the LLM will generate changes with each prompt sent. This is one reason why we can’t guarantee that the response the LLM generates will be exactly what your user will want. AI is not replacing humans completely. Humans are crucial to the success of generative AI. You’ll work with leaders at your organization to ensure that you stay compliant with your company’s ethical guidelines and domain experts will be the “humans in the loop” as you roll out trusted AI with Salesforce.

How does this affect your application lifecycle management? In addition to unit testing your features, you’ll want to ensure an ethical review of your use cases happens before your start to configure your application. After you’ve built your prompt templates and you’ve tested in a sandbox, we recommend a pilot release to production where your domain experts will continue to test and provide feedback. Feedback will be used to ensure quality and allow you to further refine your prompt templates before a larger beta release.

5. Einstein has a consumption based model

In a technical blog we don’t typically talk about pricing, but architects should be aware that Einstein is billed based on usage. This is a notable change for Salesforce architects who are not used to a consumption based model. For context, this approach is in line with the way LLM providers calculate the use of their products. If you want an example of how an LLM calculates usage you can explore the OpenAI Tokenizer.

Salesforce’s unit of measure for usage is called a credit. Credits are consumed based on the length of the inputs (prompts) sent to the LLM and the outputs (responses) generated back to Salesforce. It’s definitely something architects should be aware of. Keep in mind, however, that this is just an overview of how the pricing model works. Contact your AE to speak about specific pricing for your organization.

Conclusion

As a customer’s most trusted technical resource, architects need to truly understand how Salesforce products work so they can credibly advise on an optimal approach. I hope that this blog has provided insight into Salesforce’s AI platform, and that you’re inspired to continue to learn more about this exciting technology. Be sure to download the system landscape diagram pictured above, explore roadmap and release artifacts in the AI project resource gallery, and visit the Template Gallery on architect.salesforce.com for even more diagrams.

Resources

• Einstein System Landscape Diagram
• Einstein Architecture in Less Than 4 Minutes!
• AI Project Resource Gallery
• Template Gallery
• architect.salesforce.com

5 Things Architects Should Know About Einstein was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

Salesforce Data Cloud helps you connect and harmonize large volumes of data to create customized experiences for your customers at scale. And if you’re a Salesforce architect, you need to know how Data Cloud works. As companies race to adopt generative AI, the importance of data is more tangible, and more urgent, than ever before. In this blog I’ll discuss five key concepts that architects need to know about Data Cloud now. Let’s dive in.

1. Data Cloud data is stored in a different type of database.

Data Cloud can handle petabyte scale data because the storage layer is not the same relational database that we are used to working with. Data Cloud stores all it’s data in a data lakehouse. Under the hood this data is stored in a Parquet file format in S3 buckets. Apache Parquet leverages a columnar file storage format which, unlike the row-oriented CSV data format, is designed for large sets of complex data. On top of the columnar storage we leverage Apache Iceberg, which is an abstraction layer between the physical data files and how they are organized to form a table. Iceberg supports supports data processing frameworks like Apache Spark, Apache Presto and ultra-performant query services like Amazon Athena and Amazon EMR. All of this technology together is what supports the management of record-level updates and SQL queries in the Data Cloud data lakehouse. The diagram above details the additional technology that powers Data Cloud.

2. Data Cloud uses a new set of objects.

You might have heard that Data Cloud supports structured and unstructured data. This is true. But the power of Data Cloud comes from enforcing structure on this data by transforming it. To support the the transformation process there are three new types of objects you should become familiar with.

• Data Source Object (DSO) — The original data source in the original file format.
• Data Lake Object (DLO) — The data after it’s been transformed and stored in the data lake in the Parquet format.
• Data Model Object (DMO) — The data after it’s been mapped to the Salesforce metadata structure.

Data Model Objects are what are represented on the Customer 360 Data Model. Want to learn more about Data Model objects? This a good place to get started: Customer 360 Data Model for Data Cloud.

3. Data cloud leverages industry standard formats.

Remember how we spoke about Parquet and Apache Iceberg? These are industry standard formats. We leveraged Parquet because it is an open-source format that is supported by other Cloud providers like Snowflake. But we also contributed back to the open source community. Traditional data lakehouses are built for batch processes, but we have added capabilities that support both batch and streaming events at scale. Iceberg is also a community-driven open-source format.
Because we are using these industry standard formats we are able to architect things like the live query functionality which will allow other data lakes, like Snowflake, to query the data in DMOs without actually moving or copying the data.

4. You can interact with Data Cloud data using Platform capabilities.

If we’re leveraging all this open-source technology, why choose Salesforce over rolling your own solution? For one, since we are mapping all this data to our metadata structure and copying that metadata structure back to the lakehouse, we are able to act on this hyperscale data with the capabilities we know and love from the Salesforce Platform. This data, modeled as Data Model Objects (DMOs) is what supports all the functionality like identity resolution, segmentation, activation and, of course, Einstein services. There are also out-of-the-box features (like the Customer Data Profile) that allow you to visualize your Data Cloud data right from the core Salesforce Platform, without building a custom UI.

5. You can choose to send Data Cloud Data back to the transactional database.

Information from Data Cloud does not automatically go back to the source system (for example, Sales or Service Cloud), but there are certain components that you can leverage to see data cloud data alongside the transactional database data. For example you can see the segments a contact is in from a Contact record. What if you need to push data that is derived from Data Cloud back to Sales or Service Cloud or even Marketing Cloud? Leverage Data Actions which allow you to send information using Platform Events or Flow.

Conclusion

As a customer’s most trusted technical resource, architects need to truly understand how our products work so they credibly advise on the optimal solution. I hope that this blog has provided insight into Salesforce Data Cloud and that you continue to learn more about this exciting technology, especially as the need to bring together different data sources to get a complete view of your customer becomes even more critical to fuel AI capabilities. Be sure to download the Data Cloud Technical Capability Map and visit the Template Gallery on architect.salesforce.com for even more diagrams.

Resources

• Apache Iceberg
• Apache Parquet
• Data Actions
• Data Cloud Technical Capability Map
• Template Gallery
• architect.salesforce.com

5 Things Architects Should Know About Data Cloud was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.

In July we have some exciting new updates coming to Well-Architected and Decision Guides. We also have new blogs in store for you exploring topics like multi-cloud architecture and the human side of Well-Architected solutions. Our Call for Content will be closed this month while we review all the amazing submissions we received, but now is a great time to review our submission guidelines now because our Call for Content reopens next month.

Let’s take a quick look at some of what you can expect in July.

On the Blog:

• A Framework for Reusable Record-Triggered Flows - Learn how to leverage a reusable record-triggered Flow framework that will help improve maintainability and scalability as your automation landscape grows.
• 5 Things Architects Should Know About Data Cloud’s Architecture - How is Data Cloud different from the core Platform? What tech stack supports this hyperscale database? Learn the answers to these questions and more in this blog which highlights 5 features of Data Cloud that architects need to know.
• B2C Transactional Messaging with Service, Commerce and Marketing -Transactional messaging is a key topic in Business-to-Consumer (B2C) scenarios. It requires fast communication between many systems. In this blog you’ll learn the problems that arise for transactional messaging and potential solutions to solve them.
• Emotional Intelligence: The Human Side of Delivering Well-Architected Solutions - Psychological safety underpins team performance. Without it, it is nearly impossible to design and build a robust, Well-Architected solution that can successfully deliver value to the customer. This blog explores the human-centered skills that every architect should cultivate to lead high performing, emotionally intelligent teams.

On architect.salesforce.com:

Updates to Well-Architected: We’re working on a set of major updates to Salesforce Well-Architected, based on feedback we’ve gotten from the ecosystem and inside Salesforce. We’ll publish a more detailed walkthrough on the blog when the next release is live, but you can expect to see:

• Changes to the order of some sub-topics, to better reflect the priority of real-world implementation issues and trade-off evaluations
• More patterns & anti-patterns
• Accuracy updates for product or roadmap guidance that’s changed since August 2022
• Updates to Building Forms & Record-Triggered Automation Guides: We’re releasing updates to the Architect’s Guide to Building Forms on Salesforce & Architect’s Guide to Record-Triggered Automation on Salesforce. Our Architect Decision Guides help you choose the right tools for the right reasons, and walk through tradeoffs between tools and approaches.

On YouTube:

• Data Cloud Technical Capability Map: Step through the technical capabilities of Data Cloud and the products that power them.
• EinsteinGPT Architecture in 90 seconds: A whistle-stop tour of the architectural design of EinsteinGPT.
• 5 Things Not To Do with Mulesoft Composer: Anti-patterns to avoid when leveraging Mulesoft Composer.

On LinkedIn and Twitter:

• What Not to Do on Salesforce (#WNTDOS) rolls on with more quick takes on what to avoid when designing solutions on the Salesforce Platform and what to do instead.

What You Can Do Now:

• Follow us on LinkedIn and Twitter to make sure you don’t miss our quick takes.
• Catch up on our June blog posts, including Experience Cloud Security for Architects, Solve Problems with Salesforce Well-Architected, and A day in the life of a Composable Storefront Request.

July 2023 Sneak Peek was originally published in Salesforce Architects on Medium, where people are continuing the conversation by highlighting and responding to this story.