Salesforce News

Salesforce Flows can do a lot, and as they grow, they can quickly become complex. When a flow contains many elements and handles multiple parts of a process, finding the specific logic you are looking for can become difficult. This is even more challenging for someone who didn’t build the flow in the first place. To improve readability and keep the canvas cleaner and easier to understand, Salesforce introduced a new element called Group. With the Group element, you can simply organize related elements together directly on the Flow canvas. This makes complex flows much easier to navigate and understand. How to Use the Group Element Using the Group element is very simple. In Flow Builder, you can add a Group to the canvas just like any other element. Then, you can place related flow elements inside the group to organize them as part of the same logical section. For example, if part of your flow retrieves Asset records, loops through them, and adds them to a collection, you can place all of those elements inside a group called Prepare Asset Data. This makes it immediately clear what that section of the flow is responsible for. You can also collapse or expand a group directly on the canvas. Collapsing groups can significantly reduce the amount of space used by complex sections of a flow. This makes it easier to focus on the part you are currently working on. When you need to review the details, you can simply expand the group again. It is important to highlight that Groups do not change how the flow runs. They are just for organizing the canvas and improve readability. You can also ungroup, cut, copy, and delete groups, which makes them even more useful when reorganizing a flow. For example, you can copy an entire group when you need to reuse a similar section of logic. Or, you can move a group to another part of the flow. These options make it much easier to restructure complex flows without managing each element individually. Here is the Group element in action: The post Make Flows Easier to Read with the New Group Element appeared first on Salesforce Time.

If you use Salesforce every day, you already use the Recently Viewed list view. It’s the system list view that sits in the list view dropdown of almost every object. It shows the records you opened lately, most recent first. It’s personal, automatic, and needs no setup. Every user sees their own history, and it’s often the fastest way back to the account you were working on five minutes ago. Now try to recreate that in Flow. When you use Get Records, you can filter and sort by plenty of fields, but you can’t simply sort by view date. Flow has no built-in “recently viewed” switch. The data exists in Salesforce, but Get Records won’t hand it to you directly. In this post, you’ll learn how to find the recently viewed records in Flow. Then we’ll put it to work by building a Recently Viewed data table for the Account object. Using the Recently Viewed Object Sorting by LastViewedDate in a Get Records element sounds like it should work. Unfortunately, it doesn’t, and no single Get Records element will give you those records. Salesforce keeps this data in a special object called RecentlyViewed. It stores the records the current user viewed lately, and only for the current user, so there’s no need to filter by user. You can query it with a Get Records element like any other object, but that’s only half the job. It holds little more than the record IDs, not the fields you actually want to display, like the account’s industry, phone, or owner. To build a useful list, you’ll need a second step that takes those IDs and retrieves the full records. Let’s build a Screen Flow that displays the current user’s recently viewed Account records. Building a Screen Flow to Display the Recently Viewed Account Records 1- Create a Screen Flow and add a Get Records element to get the recently viewed Account records. As you can see, the only filter condition is the Type. 2- Use a Transform element to prepare a text collection of Account record IDs. 3- Add another Get Records element to get the Account records. You’ve found the right records, but they’re not in the right order! There’s no easy way to sort the Account records, because the field you need for sorting lives in the other collection, RecentlyViewed. So first, we’ll use the Transform element to join these two collections. 4- Add a Transform element to join the collections. Select the two collections as the sources and set the target to an Account record collection. Then choose Id as the join key. Select the fields you want to display. For example, Name, Industry, Type, and LastViewedDate. Finally, map the selected fields to the target collection. 5- Add a Collection Sort element to sort the joined Account collection by the LastViewedDate. 6- That’s it! Let’s use a Data Table to display these Account records. Add the fields you want to display. Unlike the standard list view, you can even show the Last Viewed Date! In the end, it will look like this: The post How to Find the Recently Viewed Records in Flow appeared first on Salesforce Time.

AI is becoming part of everyday Salesforce work. Developers are using AI to understand code, troubleshoot issues, build Flows, review Apex and plan new features. Admins are using it to understand configuration and solve problems faster. But there is still one common problem. AI may know Salesforce, but it does not automatically know your Salesforce org. Every Salesforce org is different. Your company may have its own custom objects, fields, Flows, Apex classes, integrations, naming conventions and business processes. So when you start a new AI session, you often have to explain the same things again. What does this field mean? Which Flow controls this process? Which integration updates this record? Is there already an automation doing something similar? What should the AI avoid changing? That repeated explanation takes time, and without the right context, AI can also suggest something that does not fit your existing Salesforce setup. This is Where Salesforce MCP Compass Comes In Salesforce MCP Compass is designed to give AI a reusable understanding of your Salesforce org. Instead of starting every AI conversation from zero, the AI can work with context about your existing objects, Flows, integrations and development conventions. The idea is simple: Give AI the Salesforce context once, instead of explaining your org again and again. It is also designed to work across different AI tools, including Claude, Cursor, Codex, GitHub Copilot and Windsurf. So the Salesforce knowledge is not tied to just one AI platform. Why Salesforce Context Matters Imagine asking an AI tool: “Add a field and update our Lead assignment process.“ Without understanding your org, the AI may suggest creating a new field without knowing that a similar field already exists. It may recommend creating a new Flow when there is already an existing automation handling part of the process. Or it may suggest an approach that does not follow the way your Salesforce team normally builds things. With better org context, AI can first understand what is already there. It can see the existing Salesforce structure and provide suggestions that better fit the current setup. This can help reduce unnecessary duplicate configuration and avoid creating more technical debt. It Also Helps When People Leave A lot of important Salesforce knowledge lives with the people managing the system. An admin may know why a particular Flow was created. A developer may know which Apex class should not be changed without checking an integration. A consultant may understand why certain fields have unusual names. But what happens when that person leaves? The next person often has to spend time going through documentation, old tickets, Flows and code just to understand how everything works. MCP Compass is designed to make that organisational knowledge more reusable. Instead of important context living only in someone’s head, it becomes available as part of the knowledge layer that future developers, admins and AI tools can use. Making New Team Members More Productive The same problem happens when a new Salesforce developer or admin joins the team. Before making changes, they first need to understand the org. They need to know: What automations already exist How important objects are connected Which integrations are running What development conventions the team follows Which parts of the system depend on each other With Salesforce context available to AI, a new team member can ask questions such as: “How does our customer onboarding process work?“ or “What automation is connected to the Opportunity process?“ Instead of receiving only a generic Salesforce answer, the AI has better context about the actual environment the person is working with. That can make it easier for new team members to understand the org before making changes. Better Planning for Larger Salesforce Changes Context becomes even more important when the project is bigger. For example, a company may want to introduce a new approval process, integration or automation. A generic AI tool might recommend the technically correct Salesforce approach. But technically correct does not always mean correct for that particular org. There may already be existing automation, integrations or business rules that need to be considered. When AI has better knowledge of the existing Salesforce architecture, it can help the team plan around what is already there rather than starting from assumptions. This can lead to better design decisions before development even starts. How Salesforce MCP Compass Works The process is straightforward. First, MCP Compass is added to the AI development environment. It then connects to the Salesforce org using read-only access. The purpose is to understand the Salesforce environment, not to make changes to it directly. From there, the Salesforce knowledge can be reused across supported AI tools and future sessions. So instead of repeatedly explaining the same architecture, the AI starts with more of the context it needs. The Real Value is Not More AI The value of MCP Compass is not simply adding another AI tool to your Salesforce environment. It is about making the AI tools your team already uses more useful. Without context, AI can spend time asking questions, making assumptions or suggesting generic solutions. With context, it can better understand the Salesforce environment before helping your team. That can mean: Less time explaining the same Salesforce setup Better continuity when team members change More consistent AI-assisted development Fewer suggestions that conflict with existing automation Better planning around the current Salesforce architecture Easier adoption of different AI development tools Your AI Knows Salesforce. But Does It Know Your Salesforce? Salesforce orgs grow over time. New fields are added. Flows are created. Integrations are connected. Business rules change. Developers and admins come and go. All of this creates knowledge that is specific to your organisation. Giving an AI tool access to Salesforce is only one part of the equation. The AI also needs to understand what your Salesforce setup means and how the different pieces work together. That is the problem Salesforce MCP Compass is designed to solve. Less time explaining your org. More time actually getting work done. Salesforce MCP Compass

Salesforce announced at Dreamforce 2026 that the Trailblazer Community is moving to Slack. The new experience expected to launch in November 2026. This is more than Salesforce launching a new Slack community. The existing Trailblazer Community online forums will transition to the Trailblazer Community on Slack. This means that Slack will become the new home for community discussions, questions, learning, and connections. For years, the Trailblazer Community has been where Salesforce professionals ask questions, share knowledge, connect with others, and learn from the wider ecosystem. Salesforce is now reimagining that experience around more real-time and conversational interactions. What Will the Trailblazer Community on Slack Look Like? Users will be able to join communities based on their location, role, products, and interests. During onboarding, they will select their interests and receive a tailored set of Slack channels. Slackbot will also help users discover relevant channels, trusted answers, and Trailhead learning resources. It will make it easier to find the right information without manually searching through different parts of the community. Salesforce is also introducing an Answers Agent. Users will be able to ask questions and receive AI-generated answers based on trusted community knowledge. At the same time, the traditional community aspect will remain. Trailblazers will still be able to ask questions, share knowledge, and interact with other community members, Salesforce MVPs, and product experts. Only now through Slack instead of the existing forum experience. Coming in November 2026 Salesforce is currently giving Trailblazers an early look at the new experience during Dreamforce and through an online research experience. The company is collecting feedback around onboarding, channel discovery, and Q&A before the broader launch. This is a major change for one of the longest-running parts of the Salesforce ecosystem. Instead of navigating traditional community forums, Trailblazers will soon be able to learn, ask questions, and connect with the Salesforce community directly in Slack. The post Trailblazer Community is Moving to Slack appeared first on Salesforce Time.

Salesforce Flow has become the go-to automation tool on the Salesforce platform. Today, you need Flow for almost any type of automation, from updating records and guiding users through business processes to integrating systems and building custom logic. Even with Agentforce, many actions ultimately rely on flows to perform the actual work. As a result, the number of flows in a Salesforce environment can grow very quickly. As that number increases, keeping flows organized becomes both more difficult and more important. With the Winter ’27 release, Salesforce introduced a new feature that makes Flow organization much easier: Flow Tags. You can now create tags and apply them to your flows. It gives you a more flexible way to categorize, find, and manage your automations. What Are Flow Tags? Flow Tags let you label your flows so you can categorize and find them more easily. You can assign multiple tags to the same flow, which lets you organize a flow in several different ways without depending only on its name. For example, you can tag a record-triggered flow that updates Account records with Sales. You organize tags under Tag Categories. Each category represents a type of information that you want to use to classify your flows. For example, you can create a Business Area category and add tags such as Sales, Service, Finance, and Marketing. With this structure, you can organize your flows based on the criteria that matter most in your Salesforce environment. How to Create Tag Categories and Tags Before you assign tags to your flows, you first need to create the tag categories and the tags that belong to them. Open the Automation app in Salesforce and go to the Tags tab. From there, you can create a new tag category and add the tags that you want to use under that category. For example, you can create a category called Business Area and add tags such as: Sales Service Marketing Finance When you create your categories, think about how you actually want to find and manage flows later. Instead of creating too many highly specific tags, use broader categories that you can reuse across many flows. Once you create your tag categories and tags, you can start assigning them to your flows. How to Assign Tags to Flows After you create your tag categories and tags, you can start assigning them to your flows. Open the Automation app and go to the Flows tab. Find the flow you want to organize, open the row-level actions, and select Assign Tags. Then choose the tags you want to apply and save your changes. You can assign multiple tags to the same flow. For example, you can tag a flow with Sales under the Business Area category and Approvals under the Purpose category. You can also assign tags while saving a flow in Flow Builder. When you use Save As, Salesforce lets you select tags as part of the flow details. How to Find and Filter Flows Using Tags Okay, you added tags to your flows, then what? The real value of Flow Tags comes from using them to find and organize your flows more easily. Open the Automation app and go to the Flows tab. Add the Tags column to your list view if it is not already visible, so you can quickly see which tags each flow has. You can also filter the list by tags. For example, if you only want to see flows related to Sales, filter by the Sales tag. You can narrow the list further by combining tags, such as Sales and Integrations. You can also open an individual Tag record to see which flows use that tag. The tag record page includes a related list of flows, which gives you another convenient way to review all automations associated with a specific business area or purpose. For example, if you open the Sales tag, you can quickly see all flows that you classified under Sales without building a separate list view or filter. This becomes especially useful in orgs with a large number of flows. Instead of relying only on flow names or scrolling through a long list, you can use tags to focus on a specific business area or purpose. One important thing to know is that this functionality is available in the Automation app, not from the regular Flows page in Setup. If you continue managing your flows only from Setup, you won’t get the same tag-based organization experience. The post How to Use Tags to Organize Flows in Salesforce appeared first on Salesforce Time.

**Written by Dorian Sabitov and Antonina Kharchenko After stabilizing customer identity and line-item mapping, it is common for teams to believe the hardest part of Salesforce–QuickBooks synchronization is already done. In reality, this is where a different class of failures begins. Most real-world sync problems are not clean successes or clean failures. They are partial successes followed by retries. What the Problem Looks Like in Practice Across real-world implementations, this problem shows up in several recurring forms: Duplicate invoices are created after a retry, even though the first attempt partially succeeded. Line items were duplicated or orphaned because header records were created, but detail records failed. “We re-ran the job, and now everything is doubled” scenarios. Finance discovers multiple invoices with the same amounts, dates, or references. Teams turn off retry capabilities entirely because retries “make things worse”. From the outside, this often looks like a random connector bug. In practice, it is a predictable outcome of an unstable design. Why It Happens Teams that integrate QuickBooks and Salesforce often treat invoice creation as a fire-and-forget operation: Attempt to create the invoice If the call fails or times out, retry Assume a retry is safe That assumption is frequently wrong. QuickBooks may successfully persist part of the transaction before returning an error or timing out. Salesforce, upon failure, retries the operation, creating a second invoice or duplicating line items because it has no reliable way to know what has already succeeded. This problem is amplified when: External IDs are stored only at the invoice header level Line items are created in separate API calls Retry logic is handled generically rather than transaction-aware At that point, retries stop being a recovery mechanism and start becoming a data corruption mechanism. Unlike mapping errors, duplicate-creation failures do not just affect structure, they affect money. Duplicates created by retries often temporarily inflate revenue, require manual voiding or deletion, break audit trails, and introduce reconciliation work that is difficult to automate. Worse, the longer these issues go unnoticed, the harder it becomes to determine which invoice was “real” and which was accidental. This is why teams often report that sync issues only become visible during month-end close, audit preparation, or customer disputes. How to Fix It 1) Design transaction creation to be safely repeatable without creating duplicates. Every invoice and every line item needs a deterministic external identifier that survives retries. If the same request is processed twice, it must result in an update, not a second creation. 2) Separate create and update paths explicitly. Retry logic should never blindly re-execute “create” operations. Integrations need to know whether they are: creating something new, or reconciling something that partially exists 3) Treat retries as a recovery workflow, not a loop. Retries should include: verification steps reconciliation checks and controlled resolution of partial states 4) Build reconciliation into normal operations. Comparing counts, totals, and identifiers between Salesforce and QuickBooks is not an audit-only activity. It is part of keeping a long-running sync trustworthy. Failures are inevitable in distributed systems, but uncontrolled retries should not lead to financial data corruption. A well-designed QuickBooks Salesforce integration focuses on preserving financial accuracy when issues occur, reducing the risk of duplicated revenue, loss of trust, and ongoing manual cleanup. Why This Matters in Production Partial sync failures are particularly dangerous because they create data that appears valid but is structurally incorrect. Unlike mapping or identity issues, these problems often remain hidden until reconciliation or audit. In the next post, we examine how sync jobs fail under real conditions: timeouts, “Bad Gateway” errors, and poor observability. Antonina Kharchenko is a Salesforce Admin with six certifications and a 2-Star Ranger on Trailhead. She works with Salesforce systems, automation, and process improvement, and enjoys turning her day-to-day experience into useful articles. Dorian Sabitov is a 4x Certified Salesforce Administrator and Developer with extensive experience in customizing Salesforce to the client’s needs. He started his journey in IT as a CRM admin and kept his focus on the Salesforce ecosystem. He loves exploring new integrations in Salesforce and spotting alternative ways to optimize business processes inside the CRM. He is currently working as a full-time Salesforce developer and contributing content to the SFApps.info educational portal.