Week 25: Capstone: Data Model, ACLs, Business Rules & a Flow

1. Scoping the Capstone

The capstone is the Equipment Request app you began scaffolding in Week 21 — a small internal tool where employees request equipment, requests route to an approver based on a simple stock-threshold rule, and everything runs through a Service Portal frontend you'll build in Week 26. Scope it deliberately small and complete rather than large and half-finished:

• Core flow: an employee submits a request → it auto-approves if stock is sufficient, or routes for manual approval if not → the requester sees status update in the portal.
• Roles: a requester (any authenticated user) and an approver (a custom role you'll create).
• "Done" means: the full flow works end to end through the portal, is covered by at least two ATF tests, is secured by real ACLs (not just admin-only access), and is packaged in a way you could hand to someone else to install.

2. Finalizing the Data Model

Building on Week 21's plan, lock the final schema before writing any automation against it — changing a table's shape after ACLs and a Flow already depend on it is exactly the rework Week 21 was trying to help you avoid.

- requested_item     (reference -> x_yourco_equip_catalog)
- quantity           (integer)
- justification       (string, multi-line)
- approval_status     (choice: Pending / Auto-Approved / Approved / Rejected)
- approved_by         (reference -> sys_user, nullable)

Confirm equip_catalog's available_stock field from Week 21 is populated with real numbers for every seeded item — the auto-approval logic in Section 4 depends on comparing a request's quantity against it.

3. ACLs: Who Can See and Touch What

Apply Week 7 for real. At minimum:

• Table-level read ACL on equip_request: a user can read their own requests (caller_id == gs.getUserID()), or anyone can if they hold the new x_yourco_equip.approver role.
• Table-level write ACL: only the record owner can write while approval_status is Pending; only an approver can write approval_status itself.
• Create a custom role (x_yourco_equip.approver) and assign it to a test user distinct from your admin account.

4. Business Rule + Flow: Auto-Approval Logic

Split the automation deliberately across the two tools from Weeks 5 and 18, using each for what it's actually good at:

(function executeRule(current, previous) {
  var catalogItem = new GlideRecord('x_yourco_equip_catalog');
  if (catalogItem.get(current.requested_item)) {
    var stock = parseInt(catalogItem.getValue('available_stock'), 10);
    if (current.quantity <= stock) {
      current.approval_status = 'auto_approved';
    } else {
      current.approval_status = 'pending';
    }
  }
})(current, previous);

Then build a Flow (Week 18) triggered on equip_request created with approval_status = Pending: notify the approver role, and create an Approval record they can act on — deliberately using Flow Designer here rather than a second Business Rule, since "notify someone and track an approval decision" is exactly the multi-step, cross-record automation Week 18 said Flow Designer fits better than a Business Rule.

5. Server-Side ATF Coverage

Before moving to the frontend in Week 26, cover the backend logic per Week 23:

• A server-side test confirming a request under the stock threshold ends up Auto-Approved.
• A second test confirming a request over the stock threshold ends up Pending, and that the Flow's Approval record was created.

6. Part 1 Checklist — Before Moving to Week 26

Confirm each of these honestly before starting the frontend half: