When creating your own Workflows, there are specific examples of what are good candidates and what are not. Workflows at their core are bundles of any metadata components that can be consistently deployed, customized, and reused across different environments. We like to think of them at the user story level, completing a solution by deploying the configuration.
This article covers the characteristics of a good workflow, the common pitfalls to avoid, and best practices for thinking about workflow design.
Workflows must be Metadata
A workflow has to be built on a bundle of Salesforce metadata. That means:
Each component of the workflow (fields, objects, permissions, rules, etc.) is defined clearly as metadata.
Variables should be used wherever the workflow may differ across environments, making it adaptable and reusable.
Why metadata only? Swantide does not access your record level data and therefore cannot deploy record level data, only your metadata can be scraped and deployed. But rest assured, metadata covers the majority of Salesforce configurations.
Characteristics of a Good Workflow
The best workflows share these traits:
Reusable – They apply across a range of customers or internal use cases.
Clear Customization Points – They have well-defined variables where inputs may differ (e.g., object names, field labels).
Efficient – They replace tedious, manual, time-consuming builds.
Accelerates Delivery – They shorten project timelines and reduce repetitive work.
Marketable – Sometimes workflows can be packaged and positioned as offerings (e.g., industry-specific quickstarts).
The Do’s of Workflow Building
When designing your workflow, keep in mind:
Do think about repeatable patterns – Focus on processes many teams or customers share.
Do compartmentalize builds – Break down into smaller, self-contained pieces that can be combined.
Do focus on shared outcomes – What are the common goals your users want to achieve?
Do design at the user story level – Each workflow should solve a clear, specific need.
The Don’ts of Workflow Building
Avoid these traps:
Don’t convince yourself your builds are too custom to be templatized – Even in unique environments, there’s always a shared pattern. And the value of Swantide variables is that even the most complex customizations can be variabilized (think time stamp objects and flows for any field or value of your choosing).
Don’t build for edge-case integrations – One-off scenarios reduce reusability, don't go for configurations you'll only need once.
Don’t design at the organization-wide level – Too broad to maintain or reuse effectively.
Key Takeaway
A good workflow is metadata-based, reusable, and focused on shared outcomes. By approaching workflows as modular, customizable assets instead of one-off builds, you save time, reduce complexity, and create repeatable value for your organization or customers.
don't go for configurations you'll only need once.
Don’t design at the organization-wide level – Too broad to maintain or reuse effectively.
Industry Examples
Check out some common use cases and ideas to get started:
SIs:
Think about the things you do when you get into every org, or the solutions you build for your specific customer types, you can build your own Workflows with variables to deploy with customizations based on the target organization.
Flows you build with the same theme across your industry customers
Reports/Dashboards that you are remaking in every org
Best practice configurations like validation rules to enforce stage progression, require fields, etc
Adding exclusion clauses to validation rules for specific profiles
Creating time stamp flows and objects for any field
ISVs:
Think about manual actions you do for net new customers, or post-deploy steps you take when releasing new updates.
Adding values to picklist fields
Adding help text to fields
Activating/de-activating flows or validation rules
Adding fields to page layouts
Deploying reports/dashboards with running user as variable
Deploying custom objects / custom fields
Copying managed flexi pages for updates