Why naming conventions matter for FlexCards
Consistent naming conventions improve maintainability, speed up onboarding, and make reuse and governance easier when building OmniStudio (Vlocity) FlexCards. Clear names reduce ambiguity when multiple developers collaborate and help admins locate elements quickly in large implementations.
General principles
Follow these core principles when naming FlexCard assets and components:
– Be descriptive but concise. Include purpose, object/context, and intent.
– Use a consistent separator (hyphen or underscore) across all assets.
– Encode metadata: environment, domain, or channel when helpful (e.g., QA, PROD, Mobile).
– Avoid special characters and spaces. Stick to alphanumerics, hyphens, and underscores.
– Use PascalCase for component names and kebab-case for file-like identifiers, if that fits your team’s style.
Recommended naming pattern
Use a predictable, tokenized pattern so names are immediately actionable. A common pattern:
FC-[BusinessDomain]-[Object]-[Purpose]-[Variant]
Where:
– FC = FlexCard prefix (helps filter and group assets)
– [BusinessDomain] = e.g., Sales, Service, Billing
– [Object] = Salesforce object or data source (Account, Case, Order)
– [Purpose] = List, Detail, Summary, Search, Header, Tile
– [Variant] = Mobile, Desktop, Condensed, Expanded (optional)
Examples
Practical examples using the pattern above:
FC-Sales-Account-Detail-Desktop
FC-Service-Case-Summary-Mobile
FC-Billing-Order-List-Condensed
Component and element naming inside a FlexCard
For internal elements (bindings, actions, DataRaptors, Integration Procedures, Attributes):
– Prefix elements by type when possible: attr_, dr_ (DataRaptor), ip_ (Integration Procedure), act_.
– Use semantic names for attributes: attr_accountId, attr_isPremiumCustomer.
– For actions: act_navigateToAccount, act_refreshCard.
Versioning and environment metadata
If your team needs to manage multiple versions or environment-specific cards, append a version or environment token:
FC-Sales-Account-Detail-v1
FC-Sales-Account-Detail-QA
Prefer a proper source control/versioning system for major changes rather than embedding large version numbers in the name. Use tokens for short-lived environment flags only.
Best practices checklist
– Define and document the naming convention in a team style guide.
– Keep names under a reasonable length (recommend < 60 characters) for UI display.
– Use prefixes (FC_, dr_, ip_, attr_, act_) to quickly identify asset type.
– Avoid using environment names for published production assets.
– Include the object or business domain to support discoverability.
– Review and refactor legacy names when consolidating solutions.
Common pitfalls to avoid
– Using vague or generic names like FlexCard1 or Card_Temp.
– Mixing multiple naming styles across teams.
– Overloading names with too many tokens that make them unreadable.
Quick reference (cheat sheet)
– Prefix for card: FC
– Separator: hyphen - (recommended)
– Component prefixes: attr_, dr_, ip_, act_
– Pattern: FC-[Domain]-[Object]-[Purpose]-[Variant]
Following a clear naming convention for FlexCards improves team collaboration, reduces debugging time, and makes large OmniStudio implementations much easier to manage. Start with a simple pattern, document it, and iterate as your org scales.