Salesforce Omnistudio Developer

A component built in a sandbox has to reach production intact. You learn what each component depends on, how to package and deploy it, and how to confirm it still behaves once it lands, so a release never breaks a live process.

• What a component depends on
• Exporting and importing components
• Deploying with Salesforce release tools
• Activation state after a deployment
• Checking a deployment in the target org
• Common deployment faults and how to recover

You build A deployment checklist, proved by moving one working component between two orgs.

A Flexcard puts the right data in one place. You connect a card to a data source, lay out its elements, and use states and conditions so the same card reads clearly for a customer, an account or a case.

• Choosing a data source for a card
• Fields, text, images and other elements
• States and conditions that change what shows
• Child Flexcards and repeating records
• Reading and shaping the data a card receives

You build A Flexcard that summarizes a customer and changes its layout by customer status.

A card earns its place when people can act from it. You add actions, feed context into the card, style it to match the page it sits on, then activate and publish it so users see the version you intend.

• Navigation, event and Omniscript actions
• Context variables and record context
• Styling with themes and custom styles
• Passing data between cards with events
• Activating and publishing a card
• Placing a card on a Lightning page

You build A published Flexcard with actions that launch a process and open a related record.

An Omniscript turns a long process into guided steps. You build the structure from steps and elements, validate what users enter, and show or hide parts of the script so each person sees only what applies to them.

• Steps and the shape of a guided process
• Input elements and validation
• Display elements and text blocks
• Edit Blocks and repeating data
• Conditional views and visibility rules
• Formulas and Set Values

You build A multi-step Omniscript that collects and validates an application.

Behind every step sits a data JSON that grows as the user moves on. You learn to read it, call Integration Procedures and Data Mappers from steps, and break a large script into pieces that other scripts can reuse.

• The data JSON an Omniscript builds
• Calling Integration Procedures and Data Mappers from a step
• Pre-step and post-step actions
• Saving progress and resuming later
• Embedding one Omniscript inside another
• Navigation and branching between steps

You build An Omniscript that pre-fills from Salesforce data and saves its result on submit.

A script that works in one language and one place is only half done. You translate labels for several languages, apply habits that keep scripts small and maintainable, then activate a version and launch it where users work.

• Type, SubType and Language as a script’s identity
• Translating labels for several languages
• Habits that keep scripts small and reusable
• Activating a new version safely
• Launching from a Lightning page or a Flexcard
• Retiring an old version without breaking users

You build A two-language Omniscript, activated and launched from a Lightning page.

When several steps must run together on the server, an Integration Procedure does it in one call. You chain actions, branch and loop with blocks, call outside systems, and follow practices that keep the procedure fast and readable.

• Type, SubType and calling a procedure
• Data Mapper, HTTP and Remote actions
• Set Values and Response actions
• Conditional, Loop and Cache blocks
• Calling one procedure from another
• Practices: fewer round trips and clear naming

You build An Integration Procedure that reads Salesforce, calls an outside service and returns one response.

Data Mappers move data between Salesforce and the JSON your components use. You build mappers that read, save and transform records, and use formulas inside them to reshape values on the way through.

• Extract, Load and Transform mappers compared
• Mapping fields and related records
• Formulas and functions inside a mapper
• Turbo Extract for simple reads
• Keys and upserts when saving
• Testing a mapping against sample input
• When a mapper is the wrong tool

You build A set of Data Mappers that read an account and save an update with reshaped fields.

Faults hide at the joins between components. You preview each one with real data, step through a procedure action by action, handle errors so users see a clear message, and write unit tests that catch a break before a release.

• Previewing a Flexcard with real records
• Reading the data JSON in an Omniscript preview
• Stepping through an Integration Procedure
• Testing a Data Mapper with sample input
• Handling errors with try-catch and response messages
• Unit testing components before release

You build A debugging log for a deliberately broken solution, with each fault found and fixed.

A correct solution can still be slow or leak data. You cache what rarely changes, cut round trips, and apply field and record security inside mappers and procedures so each user reaches only what they should.

• Caching repeated reads
• Finding where a slow process spends its time
• Cutting round trips with one procedure
• Field-level security and sharing in mappers
• Protecting values in the data JSON
• Permission checks on the components themselves

You build A before-and-after timing of a slow process, with its security settings checked.

Build one process end to end. A Flexcard shows the customer, an Omniscript guides the request, and Integration Procedures and Data Mappers do the work behind it. You then test, break, fix and deploy it as you would at work.

• Scoping a process and choosing the components
• Building the data layer first
• Building the guided front end
• Testing and fixing faults
• Deploying to a second org

You build A complete Omnistudio service, built, tested and deployed between two orgs.