Learning Objectives :
After reading this blog you’ll be able to:
- Understand the best practices and naming conventions in Omnistudio Flexcard
- Understand the best practices and naming conventions in Omnistudio Omniscript
- Understand the best practices and naming conventions in Omnistudio DataRaptor
- Understand the best practices and naming conventions in Omnistudio Integration Procedure.
OmniStudio FlexCards displays contextual information at a glance and provides access to relevant tasks for the displayed data.
Omnistudio FlexCard Best Practices:
1. Clearly define your goals and the purpose of the FlexCard before beginning to create one.
2. FlexCards are made to convey information fast and effectively. Keep the content concise and to the point.
3. Use eye-catching visuals, crisp photos, and consistent branding elements to produce FlexCards that are visually appealing.
4. Include interactive components like buttons, tests, polls, and more. To increase user involvement and encourage engagement with your information, strategically make use of interactivity.
5. Prioritise mobile responsiveness, and make sure your FlexCard is usable on mobile devices and responsive on screens of all sizes.To make your website mobile-friendly, pay close attention to the text sizes, image sizes, and interactive elements.
6. Omnistudio offers analytics to monitor user activity on your FlexCards. Utilise these insights to determine how well your cards are performing.
7. Distribute your FlexCards through numerous methods, such as email, social media, websites, or learning management systems, after you have finished creating them. To increase the FlexCard's exposure and impact, think about embedding it on pertinent web pages or sending it to your target market.
Naming conventions in Flexcard:
Name + Author: The combination of the card Name and Author must be unique in your Org.
Name and Author can only contain letters, numbers, and underscores, begin with a letter, not include spaces, not end with an underscore, and not contain two consecutive underscores.
An OmniScript is a guided experience that takes users through complex business processes. Using its drag-and-drop editor, application builders can design seamless customer experiences across industries.
Omnistudio OmniScript Best Practices:
1. Understand the use case and create an OmniScript that provides the required functionality.
2. To make your OmniScript more reusable and maintainable, divide it up into smaller, modular components. Use sub-flows or reusable components to group together functionality that may be applied to other OmniScripts.
3. Based on the user data you need to collect, decide which screen elements (such as input fields, picklists, checkboxes, etc.) to employ.
4. Implement data validation rules to make sure that user-entered data is accurate and legitimate. Use OmniStudio's built-in validation features to enforce constraints and provide useful error messages.
5. To reduce complex branching and maintain a straightforward, understandable flow, make effective use of decision components.
6. Include the proper error handling methods in your OmniScript to take into account probable mistakes and exceptions.
7. Use error screens and other error-handling elements to gracefully manage unexpected situations and give users informative error messages.
8. Configure OmniStudio's logging and monitoring features to keep track of errors and exceptions during runtime.
9. Completely test your OmniScript to make sure all features are operating as expected.
10. Maintain proper documentation of your OmniScript, including its goal, design choices, and any particular implementation details.
Naming conventions in Omniscript
TypeSubtypeLanguage: Type, SubType, and Language combine to create a unique identifier that becomes the name of a compiled OmniScript's Lightning web component. The Type and SubType can contain letters and numbers, but no spaces or underscores and cannot exceed 104 characters.
For example, an OmniScript where Type=account, SubType=Create, and Language=English generates an LWC named accountCreateEnglish.
A DataRaptor is a declarative mapping tool that enables you to read, edit, and transform data in Salesforce. It enables admins to display and save data without the need to write any Apex. DataRaptors act as the main way to manipulate data in OmniStudio.
Omnistudio DataRaptor Best Practices:
1. Set Limit in DataRaptors
2. Extract DataRaptor should not query more than 5 objects
3. Create targeted DataRaptors that only extract or load the data needed for one operation.
4. Use relationship notation (queries) whenever possible to pull data from other SObjects.
5. Try to keep the number of SObjects to three or fewer.
6. Ensure that all filtering and sorting (ORDER BY) operations are on indexed fields. The Id and Name fields are always indexed.
7. Use caching to store frequently accessed, infrequently updated data.
8. DataRaptor Names Must be unique within the org and there should be No spaces
9. Use camelCase – prefix, Verb, Object and Detail
10. Use an action verb and descriptive nouns
11. Use abbreviations
12. Example : prefixVerbObjectDetail and teamGetAcctCases
Naming conventions in DataRaptor
Interface Name: The DataRaptor Interface Name must be unique. The Interface Name can contain letters and numbers, dashes, and underscores, but no spaces.
Integration Procedures are processes that are used to read and edit data from Salesforce or from external applications. These server-side applications allow designers to build complex data transformations without writing any code.
Omnistudio Integration Procedure Best Practices
1. Use Integration Procedures for all data calls to Salesforce.
2. In the integration procedure, use a try-catch block rather than writing apex code.
3. To trim the data and only return what is required, use a response action.
4. Use multiple Response Actions and various Execution Conditional Formulas to enable an Integration Procedure to terminate early in the right circumstances.
5. Use caching to store frequently accessed, infrequently updated data.
6. Use the following options when calling Integration Procedures to conduct data operations asynchronously:
a.When the calling OmniScript or Integration Procedure doesn't require a response and the completion time isn't crucial, use Future.
b. When the caller OmniScript must instantly invoke the Integration Procedure, use Fire and Forget instead of Use Future.
c. Use the Invoke Mode: Non-Blocking option to launch the Integration Procedure instantly and keep the calling OmniScript's user interface open. Once the Integration Procedure is finished, a response is provided.
Naming conventions in Integration Procedure
Type_SubType: The Type and SubType are joined by an underscore to create a unique identifier used to call the Integration Procedure. The Name Type and SubType can contain letters, numbers, and special characters, but no spaces.
For example, Type=Auto and SubType=CreateUpdateQuote create a unique identifier Auto_CreateUpdateQuote.