Salesforce Omnistudio Consultant

You do not build, but you must know each part well enough to advise. This module explains what Flexcards, Omniscripts, Integration Procedures and Data Mappers do, and how they hand work to one another.

• What a Flexcard is for
• What an Omniscript is for
• What an Integration Procedure is for
• What a Data Mapper is for
• How the four hand work to each other
• Reading a solution diagram

You build A one-page guide that explains each component and shows how a request flows through all four.

Cards are quick to build and easy to overload. You learn how they present context and actions, how settings and conditions change them, and the recommended limits that keep a card fast and readable.

• Context and data on a card
• Actions a card can offer
• Conditions that change what shows
• Settings and publishing in outline
• Recommended limits for card content
• Spotting an overloaded card

You build A review of a sample Flexcard design with its limit risks marked.

A script guides someone through a task, and a poor one loses them. You learn how steps, behaviors and languages shape a process, and the practices that keep a script short enough to finish.

• Breaking a process into Omniscript steps
• Behaviors that help users along
• Supporting several languages
• Practices for scripts that people finish
• Spotting a script that has grown too long
• Reuse across processes

You build A step-by-step outline of a guided process, with its language and behavior choices.

Some work belongs on the server. You learn how a procedure runs actions in order, what kinds of work it can do, and the practices that keep it dependable when many users call it at once.

• Running several steps in one call
• Kinds of actions a procedure can run
• Why order and error handling matter
• Practices for dependable procedures
• Reading a procedure outline
• Signs a procedure is doing too much

You build A written walkthrough of a procedure design for a customer lookup.

Two tools can touch data, and each suits a different job. You learn what Data Mappers read, store and update, and the rules of thumb that tell you when a mapper is enough and when a procedure is needed.

• What a Data Mapper reads and writes
• Simple data movement compared with orchestration
• Rules of thumb for the choice
• Mixing the two in one solution
• Best practices for each
• Justifying the choice to a delivery team

You build A decision table that picks mapper or procedure for six data requirements.

Requirements arrive as business needs, not components. You practice reading scenarios, choosing the combination of components that answers each one, and explaining the trade-offs to the people who will build it.

• Reading a requirement for its real need
• Choosing one component or several
• Common solution patterns
• Trade-offs between speed and flexibility
• Documenting a component choice
• Reviewing another consultant’s design

You build A solution recommendation for three requirements, each with its component choice explained.

A solution that works in a demo can fail under real use. You learn the recommended limits for cards and scripts and the practices that keep them responsive, so you can advise before a problem reaches users.

• Why limits exist
• Limits for Flexcards and Omniscripts
• Keeping data calls light
• Practices that keep scripts fast
• Warning signs during design review
• Advising a team that has passed a limit

You build A design review checklist covering limits and performance for a customer’s solution.

A plan decides whether the work lands on time. You prepare for an implementation by deciding the steps, the skills, the environments and the order of delivery, and by setting expectations with the customer.

• Discovery steps before building
• Skills a delivery team needs
• Environments and their roles
• Sequencing work across components
• Setting expectations with a customer
• Estimating effort without false precision

You build An implementation plan with phases, roles and environment steps.

Moving work between orgs and proving it works are part of the design. You compare ways of deploying components and testing them, including automated tests, and recommend an approach that fits the customer’s team.

• Moving components between environments
• Manual testing and its limits
• Automated testing approaches
• Testing with real data safely
• Release management for a small team
• Recommending an approach

You build A deployment and testing recommendation for a customer’s release process.

Take a customer’s problem from first question to recommendation. You choose the components, set limits, plan the implementation and deployment, and present advice that a delivery team could build from.

• Reading the customer scenario
• Choosing and justifying components
• Planning implementation and deployment
• Anticipating limits and risks
• Presenting the recommendation

You build A recommendation document for one customer scenario, from components to plan.