Module 5 — Real Project

Build FreshBasket Grocery, a Salesforce application for a grocery business with physical stores and online ordering. The business wants one view of customers, products, inventory, orders, payments, deliveries, loyalty, and support. Salesforce will manage customer engagement and order operations, while an external payment gateway and delivery partner may remain separate systems.

Begin with interviews instead of immediately creating fields. Speak with the store manager, cashier, customer-service agent, inventory manager, delivery coordinator, finance user, and business owner. Capture the current process, pain points, exceptions, required reports, integrations, and decisions each role must make. Convert the findings into user stories with acceptance criteria.

Define a minimum viable release before adding advanced features. A sensible first release includes customer registration, product catalog, store inventory, order capture, payment status, delivery status, support cases, dashboards, and permissions. Loyalty tiers, promotions, advanced forecasting, and sophisticated route optimization can follow after the core transaction is reliable.

Use Salesforce as the customer and order operations platform. Standard Account and Contact records represent customers, while custom objects represent Store, Product, Store Inventory, Order, Order Item, Payment, Delivery, and Loyalty Membership. Use Flow for straightforward automation, Apex for transactional or complex logic, LWC for the store workspace, and middleware for payment and delivery integrations.

Design relationships before building pages. A customer Account can have Contacts and many Orders. An Order belongs to a Store and a customer, and contains Order Items. Each Order Item references a Product. Store Inventory connects a Product to a Store and stores quantity and reorder values. Payment and Delivery relate to an Order. Use master-detail where the child cannot have meaning without its parent, and lookup where records can exist independently.

Account (Customer)
  |-- Contact
  |-- Order
        |-- Order Item -- Lookup --> Product
        |-- Payment
        |-- Delivery
  |-- Loyalty Membership

Store -- Store Inventory -- Lookup --> Product

Create custom objects with clear labels and API names. Product should include SKU, Category, Brand, Unit, Price, Tax Rate, and Active. Store Inventory should include Store, Product, Quantity On Hand, Reorder Level, and Availability. Order should include Customer, Store, Order Status, Payment Status, Total Amount, Order Date, and Delivery Address. Use currency, number, date, checkbox, picklist, formula, and relationship fields deliberately.

Use Account and Contact records for customers and household or business relationships. Capture consent, preferred language, phone, email, delivery addresses, communication preference, and loyalty membership. Add duplicate and matching rules for email and phone. Do not store payment card numbers in Salesforce; keep only a gateway token or masked reference when the integration requires it.

Create a product catalog that supports grocery categories, units, tax treatment, active dates, and store availability. Decide whether price is global or store-specific. For a first release, Product can hold a base price and Store Inventory can hold availability. A later release can introduce price books, promotions, bundles, and effective-dated pricing.

Inventory must be tracked per store, not only at the product level. Store Inventory records hold quantity on hand, reserved quantity, reorder level, safety stock, last counted date, and availability. When an order is confirmed, reserve stock; when it is cancelled, release it; when it is picked, reduce the physical quantity. Define how substitutions and damaged items affect the quantity.

Decimal availableQuantity = inventory.Quantity_On_Hand__c
    - inventory.Quantity_Reserved__c;

if (availableQuantity < requestedQuantity) {
    throw new InventoryException(
        'The requested quantity is not available at this store.'
    );
}

Define the order lifecycle before building automation. A useful lifecycle is Draft, Confirmed, Payment Pending, Paid, Picking, Partially Fulfilled, Ready for Delivery, Out for Delivery, Delivered, Cancelled, and Failed. Separate order status from payment status and delivery status so one failure does not hide the true state of the transaction.

At checkout, calculate item totals, discounts, tax, delivery fee, and grand total. Freeze the price and tax used on each Order Item so historical orders do not change when the product catalog changes. Create a Payment record with gateway reference, amount, status, and transaction timestamp. Never store raw card details in Salesforce.

Decimal subtotal = 0;
for (OrderItem__c item : items) {
    item.Line_Total__c = item.Quantity__c * item.Unit_Price__c;
    subtotal += item.Line_Total__c;
}

order.Subtotal__c = subtotal;
order.Total_Amount__c = subtotal
    - order.Discount__c
    + order.Tax__c
    + order.Delivery_Fee__c;

Use a Named Credential and middleware or a secure Apex callout to communicate with the payment provider. Send an idempotency key so a retry cannot charge the customer twice. Store the provider's transaction ID and status. Handle authorization success, decline, timeout, duplicate request, refund, and unknown status separately. A timeout should not be treated as a confirmed failure until the provider is checked.

HttpRequest request = new HttpRequest();
request.setEndpoint('callout:Payment_Gateway/charges');
request.setMethod('POST');
request.setHeader('Content-Type', 'application/json');
request.setHeader('Idempotency-Key', String.valueOf(order.Id));
request.setBody(JSON.serialize(new Map<String, Object>{
    'amount' => order.Total_Amount__c,
    'currency' => 'USD'
}));

HttpResponse response = new Http().send(request);

Store staff need a simple workspace showing the order, item quantities, aisle or category, and substitution rules. A picker can mark each line as Picked, Substituted, Unavailable, or Damaged. The system should recalculate the final amount when substitutions or unavailable items change the order and should notify the customer before delivery when approval is required.

Create a Delivery record for address, delivery window, driver or partner, status, tracking reference, dispatch time, and delivery time. Use statuses such as Pending, Assigned, Picked Up, Out for Delivery, Delivered, Failed, and Returned. Capture proof-of-delivery according to the business and privacy requirements. Keep delivery failures visible to support users.

A Loyalty Membership can relate a customer to a program and store points balance, tier, join date, and expiration rules. Award points only after the order is successfully delivered or the business-defined earning event occurs. Keep point transactions auditable instead of changing only the balance. Add communication preferences so marketing messages respect consent.

Configure record types and page layouts for customer service, store operations, inventory, and finance where the processes truly differ. Use validation rules for conditions such as requiring a cancellation reason or preventing a Delivered order from moving back to Draft. Use custom metadata for values that may change, such as reorder thresholds or supported delivery statuses, rather than hard-coding them.

Use record-triggered Flow for straightforward updates and notifications. Useful Flows include creating a Case when delivery fails, creating a low-stock task, sending an order confirmation after payment, and assigning a new customer to a service queue. Add entry criteria, fault paths, and duplicate prevention. Keep complex stock reservation and payment coordination in Apex or middleware when transaction control is required.

Use Apex for operations that must validate several records and succeed or fail together, such as confirming an order and reserving inventory. Keep the service bulkified and separate orchestration from data access. Decide where partial success is acceptable. Use savepoints cautiously because large transactions still consume platform resources.

public with sharing class OrderConfirmationService {
    public static void confirm(Id orderId) {
        Order__c order = [
            SELECT Id, Status__c
            FROM Order__c
            WHERE Id = :orderId
            FOR UPDATE
        ];

        if (order.Status__c != 'Draft') {
            throw new OrderException('Only draft orders can be confirmed.');
        }

        // Validate items, reserve inventory, and update the order together.
        order.Status__c = 'Confirmed';
        update order;
    }
}

Build a Lightning Web Component for store staff that shows today's orders, filters by status, opens an order, and supports picking actions. The component should have loading, empty, success, and error states. Use Apex for server-side authorization and transaction logic; do not trust a client-side button to enforce inventory or payment rules.

// orderWorkspace.js
import { LightningElement, api, wire } from 'lwc';
import getStoreOrders from '@salesforce/apex/StoreOrderService.getStoreOrders';

export default class OrderWorkspace extends LightningElement {
    @api recordId;
    status = 'Ready for Picking';

    @wire(getStoreOrders, { storeId: '$recordId', status: '$status' })
    orders;

    get isLoading() {
        return this.orders.data === undefined && this.orders.error === undefined;
    }
}

Create separate access for customer service, store operations, inventory, finance, delivery coordination, and administrators. Start with restrictive organization-wide defaults. Use permission sets for capabilities, roles for visibility, sharing rules for necessary collaboration, and field-level security for sensitive information. Finance users may see payment status and masked references but not secret credentials.

Publish an Order Confirmed or Order Ready event when downstream systems need to react. Middleware can transform the event for the payment gateway, delivery partner, ERP, and warehouse. Include an event ID, order ID, occurred-at timestamp, version, and only the fields consumers need. Design consumers for replay and duplicate delivery.

Order_Ready__e eventMessage = new Order_Ready__e(
    Event_Id__c = String.valueOf(Crypto.getRandomLong()),
    Order_Id__c = order.Id,
    Version__c = '1',
    Occurred_At__c = Datetime.now()
);
EventBus.publish(eventMessage);

Create dashboards for each operational audience. Store managers need orders awaiting picking, stockouts, fulfilment time, and failed deliveries. Finance needs captured payments, refunds, failed transactions, and order totals. Leadership needs revenue, repeat customers, average order value, fulfilment rate, and delivery performance. Validate report filters against real records and user visibility.

Every failure should have an owner and a recovery path. Store integration status, error category, retry count, last attempt, correlation ID, and human-readable message on an integration log or related record. Use a retry policy for transient failures and a support queue for permanent data errors. Avoid exposing technical stack traces to customers.

Test the project at several levels. Unit tests cover Apex services. Flow tests cover entry criteria, positive paths, fault paths, and duplicate prevention. LWC tests cover loading, empty, success, and error states. Integration tests cover authentication, timeouts, declines, duplicate requests, retries, and malformed responses. User acceptance testing should follow complete journeys, not isolated clicks.

@IsTest
private class OrderConfirmationServiceTest {
    @IsTest
    static void confirmsOrderWhenInventoryIsAvailable() {
        Order__c order = TestDataFactory.draftOrderWithInventory(2);

        Test.startTest();
        OrderConfirmationService.confirm(order.Id);
        Test.stopTest();

        Order__c savedOrder = [
            SELECT Status__c FROM Order__c WHERE Id = :order.Id
        ];
        System.assertEquals('Confirmed', savedOrder.Status__c);
    }
}

Prepare legacy customers, products, stores, and inventory before loading them. Define external IDs and reference mappings, clean duplicate customers, normalize phone and address values, and load parent records before children. Test a small sample first, export backups, validate record counts, and reconcile totals after the migration.

Move the solution through source control and environments in dependency order. Deploy objects and fields, permissions, flows, Apex, LWC, reports, and integrations with their required metadata. Run tests in a sandbox, train users, prepare a rollback or feature-disable strategy, and release during a support window. Use feature flags or configuration where external dependencies are not ready.

Create role-based training using screenshots from the actual configured org. Capture the Account customer view, product and inventory page, order workspace, payment status, delivery timeline, support Case, and operational dashboard. Annotate the action being demonstrated and hide personal data, tokens, and credentials before publishing an image. The repository currently has no grocery-store screenshots, so these should be captured after the project is configured in a sandbox.

Before launch, confirm that user licenses and permission sets are correct, integrations authenticate, products and inventory are loaded, reports show expected totals, automation has fault paths, payment credentials are production-ready, support owners are assigned, and backups exist. Run a smoke test for customer creation, order creation, payment, picking, delivery, cancellation, refund, and support.

For the first weeks after launch, monitor transaction volume, failed payments, stock mismatches, delivery delays, Flow errors, API limits, and user feedback. Review the backlog with business owners and prioritize reliability and data quality before adding complexity. Keep an architecture decision record so future developers understand why Salesforce, Flow, Apex, or middleware was chosen for each feature.

Present the project as a business solution, not only a collection of Salesforce features. Explain the problem, stakeholders, data model, security decisions, automation, code, integration design, testing evidence, and measurable outcomes. Include sanitized screenshots, an architecture diagram, sample user stories, and a short demo script. Do not include real customer data or credentials.