BA Academy — self-paced module
By the end of this module, you will be able to:
You will probably never be the person who builds the org's most complex automation. You will constantly be the person who decides, with stakeholders, what the automation should do, and whether it is worth doing. That requires knowing what the platform can do declaratively (with clicks, not code), what requires code, and what requires connecting other systems. This module is your map of that terrain. It also completes the "basic configuration tasks" listed among BA activities in Module 1: many BAs do hands-on configuration at exactly the level covered here.
A Lightning app is a way to control access to Salesforce functionality within an org: a named collection of tabs and components so that assigned users see only what they need. A college admissions team gets an "Admissions" app with admissions objects and tools; the registrar team gets a "Registrar" app with registrar-related objects. Apps can also be installed from the AppExchange, the marketplace where the ecosystem shares and sells solutions.
For the BA: apps are a persona concept. When your security matrix (Module 7) defines who needs what, apps define how each persona's workspace is packaged. "What should each team see when they log in?" is an app requirement.
Lightning pages are custom page layouts: they control what a record page (or home page, or app page) presents. Pages can be assigned as an org-wide default, or varied by app, by record type, and by profile: the account object's page differs from the contact page, and can differ again per audience.
Dynamic forms take this further: field and component visibility can respond to conditions, so different subgroups see different fields on the same page, or fields appear only when relevant (show "Reason Lost" only when an opportunity is lost). When stakeholders say "this screen is cluttered" or "intake needs these fields up top" (a complaint you will hear in every UAT), Lightning pages and dynamic forms are the remedy.
A field stores data (Module 6 covered the data-model view). Configuration adds the practical craft: each field has a data type (text, number, date, and so on) chosen to match the information being collected, and each field belongs to exactly one object.
Picklists deserve special attention because they encode business rules. A picklist lets users select one or multiple values from a predefined set. Global picklist value sets define a value list once and reuse it across multiple fields, with per-field restriction of which values are available. When two teams need "the same statuses, mostly," a global value set with restrictions beats two drifting copies: and knowing that shapes how you write the requirement.
Validation rules conditionally prevent a record from being saved: the platform's guardrails for data quality. Essentials worth knowing precisely:
That last property makes validation rules a favorite BA tool: a rule enforced only on one screen is a suggestion; a validation rule is policy. When a stakeholder says "records must always have X before Y happens," you are hearing a validation-rule requirement. Capture the condition, the error message users should see (write it in plain, helpful language), and the exceptions, because there are always exceptions.
Salesforce Flow is the platform's point-and-click automation tool: it creates and automates complex business processes, automating repetitive tasks and guiding users through processes, without code.
Flow's benefits: no code required (drag-and-drop building), efficiency (repetitive tasks automated, human error reduced), flexibility (update records, send emails, create tasks, and much more), and improved user experience (screen flows turn complex processes into step-by-step guidance). Distinctive advantages over the platform's older tools: interactive UI screens, mass updates and deletes across unrelated records, record cloning, loops, and decision logic: real programming power in a visual builder, growing with every release.
Two older automation tools remain visible in existing orgs and in interview questions, and both are retired features: no longer the way new automation should be built.
Treat them as historical context: you will encounter them in older orgs, and migrating their logic into Flow is a common project task (a nice example of the reverse-engineering elicitation from Module 3: the old automation is documentation of a business rule somebody once needed). Salesforce's direction is unambiguous: Flow is the preferred automation tool, and new features land there.
Several narrower automation features complete the picture, each a concept you should recognize in requirements:
An approval process automates multi-step approvals: a user (or automation) submits a record, and designated approvers manually approve or reject it, determining whether it advances. The process specifies each step, whom to request approval from, and what happens at every point.
Approval processes attach to standard or custom objects. Classic use cases: a sales rep requests a 30 percent discount, routed to their sales manager; a large-quantity quote discount routed to the sales team; an employee's leave request routed to their manager.
The anatomy:
For the BA, approval requirements are a gift: they force stakeholders to articulate exactly who may authorize what, at which thresholds, with what consequences: governance made explicit. Diagram them as swim-lane processes (Module 5) before anyone configures anything.
When a record is saved, the platform runs its many automations in a defined sequence, and knowing the outline explains otherwise-mysterious behavior ("why did the validation error appear before my assignment happened?"). The teaching mnemonic: Very Angry Admins Work Pretty Efficiently:
(The full technical order is longer and includes flows and triggers at several points; the mnemonic covers the classic sequence and is a fine interview answer at BA depth.) The BA takeaway: automations interact in sequence, which is why seemingly simple changes get tested carefully: Module 12's subject.
Four practices worth repeating to every stakeholder who wants "just a quick automation":
SOQL (Salesforce Object Query Language) is the query language used to retrieve data from the platform: similar to SQL (Structured Query Language) but tailored to Salesforce's multi-tenant, object-oriented data model.
Key points:
Reading examples (from the source material's exercises):
SELECT Id, Name, Birthdate FROM Contact
SELECT Id, Name, Birthdate, Phone FROM Contact WHERE Phone != ''
SELECT Id, Name, Birthdate, Phone FROM Contact WHERE Phone != '' OR Email != ''
The first retrieves three fields for every contact; the second only for contacts with a phone number; the third for contacts with a phone or an email. That is genuinely most of the reading fluency a BA needs: SELECT (which fields) FROM (which object) WHERE (which conditions). Writing complex SOQL is developer and admin work (and per the career ladder in Module 18, a growth skill rather than a core BA skill), but reading a query in a design document, and confirming it matches the requirement, is squarely yours.
Data migration is the process of transferring data from external systems (legacy systems, databases) into Salesforce: importing, exporting, and updating data across environments. It matters because system upgrades demand it (moving from an on-premise CRM to Salesforce), consolidation demands it (merging customer data from multiple sources into a unified view), and data quality demands it (clean, accurate data for better decisions: the Module 8 theme again).
Three types:
Tools, in ascending capability: the Data Import Wizard (user-friendly, standard and custom objects, small-to-medium volumes), Data Loader (large volumes, bulk insert/update/delete/export: both covered hands-on in Module 8), and a third-party tool category for complex migrations and real-time needs: cloud migration platforms and web-based loaders. Names in this category change; evaluate current options when a project needs one.
The BA's migration duties are larger than they look: deciding what data moves (all of it? seven years of dead leads?), mapping source fields to target fields (a document only someone who understands both businesses can write), defining quality rules for cleansing before load, and planning validation after load (row counts, spot checks, stakeholder sign-off). Migration mapping workshops are among the most BA-intensive sessions in any implementation, and they lean on every data-model concept from Module 6.
Almost no organization runs Salesforce alone. Integration is how Salesforce exchanges data and triggers behavior with everything else: the ERP, the website, the payment processor, the data warehouse.
An API (Application Programming Interface) enables different software systems to communicate: the driver of automation, integration, and business efficiency. Two API styles dominate integration conversations:
REST (Representational State Transfer): lightweight and flexible, ideal for modern web and mobile applications. Its benefits: ease of integration (quick to implement, reducing time-to-market), scalability (handles high request volumes), flexible data formats (typically JSON or XML), and cost-effectiveness (lower overhead and maintenance). Typical use cases: customer-facing applications, third-party service integration (social media, payment gateways), cloud systems and microservices.
SOAP (Simple Object Access Protocol): protocol-based, robust, and secure: common in enterprise environments where consistency, security, and reliability are critical. Its benefits: strong built-in security standards (essential for financial and healthcare transactions), reliable transaction management (supporting ACID properties: atomicity, consistency, isolation, durability), and strict standardization that eases integration with legacy systems. Typical use cases: ERP systems, banking and insurance, regulated sectors like healthcare and government.
The BA-level decision heuristic hiding in those lists: modern, fast-moving, customer-facing integration leans REST; legacy, regulated, transaction-critical integration leans SOAP. You will not choose the protocol (architects do), but requirements you gather (data sensitivity, volumes, real-time versus batch, systems involved) drive their choice, so gather them deliberately.
Middleware is software acting as a bridge between applications, facilitating communication, integration, and data flow. In Salesforce contexts, middleware connects the org with external systems (ERP, databases, third-party applications) so data exchanges reliably without every system needing to know about every other.
Categories to recognize (with a currency note: the vendor landscape shifts, so treat named examples as illustrations, not endorsements):
Common middleware use cases: ERP integration (orders, inventory, and financials synchronized between Salesforce and systems like SAP or Oracle), e-commerce integration (order and customer data flowing from storefront platforms), legacy system integration (bridging older systems without replacing them), and data warehousing (feeding Salesforce data into a central warehouse for advanced analytics).
When integration appears in discovery, the BA's questions are: which systems? which direction does data flow? how fresh must it be (real-time or nightly batch)? which system is the source of truth for each field? what happens when the other system is down? Those five questions, answered, are most of an integration requirement.
Work-tracking and DevOps platforms (Azure DevOps, Jira, and similar) also touch configuration work: teams track configuration stories, test cases, and deployments in them. As Module 10 established, this course deliberately teaches the concepts rather than any tool's mechanics: firms configure and use these platforms in their own ways, and you will learn the local dialect in your first week. No further tooling detail is needed here.
A final mental model that makes everything in this module cohere. Salesforce solution design follows a preference order:
As a BA you sit at the top of that funnel. The requirements you write, and the questions you ask ("must this be real-time?" "who approves?" "what happens on failure?"), determine how far down the funnel a solution must reach. Every notch deeper costs more to build and maintain. Requirements precision is cost control: one more reason the craft in Modules 3 and 4 pays for itself.
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.