# Equipment Request practice pack

For the JamForce Equipment Request Capstone, revised 18 September 2026.
Article: /guides/salesforce-admin-practice/equipment-request-capstone/

Use only synthetic records in a practice org or private sandbox. This pack contains expected results, not completed Salesforce tests. It does not authorise production work.

The capstone delivers one change to the Equipment Request app from Admin Essentials: approver routing moves from a formula into custom metadata, and a Finance escalation stage runs for requests over a per-team cost threshold. The historical data is the regression fixture. The live scenarios test the change and prove the original behaviour still holds.

## Files and order

1. Read the article and agree the change brief, the updated access matrix, and the acceptance criteria for the change and for regression.
2. Review historical-requests.csv against your existing imported records and record the 1720 baseline before changing anything.
3. Create the public groups and custom metadata records in routing-records.csv, in a sandbox, leaving one team deliberately without a record.
4. Build the routing flow and the new approval version. After preliminary debug checks, activate the candidate and its called flows before creating persona requests. In a sandbox, keep the previous version active in the release destination until release checks pass. In a single practice org, only one version can be active, so activating the candidate deactivates the previous version; record that state and treat its reactivation as the rollback rehearsal.
5. Run live-scenarios.csv as user actions, not an import of finished statuses. LIVE-10 to LIVE-17 test the change; LIVE-01 to LIVE-07 are regression.
6. Record observations in test-results.csv. All tests start as Not run. T-21 stands for the full acceptance table from Test Permissions and Reports; attach that table's results.
7. Record decisions in decision-log.csv, assemble evidence-index.md, and review review-rubric.csv.

The individual files are available beside this ZIP at /downloads/salesforce-admin-practice/.

## Reuse existing records

The five legacy keys are the same ones used in Data Import and Reconciliation. Reuse verified records and their evidence if you already completed that chapter. Export the current state before any new work. Do not overwrite later edits to reproduce this sample or insert duplicate copies.

For a fresh load, follow /guides/salesforce-admin-essentials/data-import-and-reconciliation/. It covers matching legacy identifiers, permissions, the narrowly scoped historical-date bypass, pilot results, upsert and recovery. Legacy_Request_ID__c must be configured as specified there. Do not upload the source worksheet directly.

## Map the source worksheet

| Source column | Salesforce destination / preparation |
|---|---|
| LegacyRequestID | Legacy_Request_ID__c; preserve the key unchanged |
| OwnerPersona | OwnerId; replace Staff A and Staff B with distinct test-user IDs in this destination org |
| EquipmentKey | Equipment_Type__c; map equipment-example to an agreed valid picklist API value; it is not a supplied Salesforce value |
| Status | Status__c; retain the historical status so this load does not submit fresh approval requests |
| BusinessJustification | Business_Justification__c |
| NeededBy | Needed_By__c; historic ISO dates are intentional; use the chapter's limited import bypass |
| ExpectedDeliveryDate | Expected_Delivery_Date__c; blank values are absent source data, not an instruction to clear existing fields |
| EstimatedCost | Estimated_Cost__c; agree one currency for all five rows and reports |
| RejectionReason | Rejection_Reason__c; 005 is deliberately missing its required reason |

Record actual test-user IDs privately. Map equipment-example consistently to the agreed value. Check each mapped value and field type in your org. The owner/team shortcut assumes each requester retains ownership and belongs to one agreed team.

## Pilot and corrected historical baseline

For a fresh load, pilot 001 and 005. Request 001 should succeed; 005 should fail the rejection-reason rule. Add this synthetic reason to 005: `Existing equipment meets the requirement.` Retry that failed row only, then complete and reconcile the load as the import chapter describes. Keep both original and corrected source files, the error, and the success evidence.

After correction, five unique records exist. Four are Approved or Awaiting Stock, with total estimated cost 1720.00. Staff A contributes 1450.00; Staff B contributes 270.00. The Rejected row contributes zero to that report because it is excluded. Filter the baseline reports to the five keys, with date and visibility filters that include them.

Historical records do not prove an approval happened. Do not create fictitious approval history. Importing old Needed By dates does not backdate Created Date or make the ageing formula count from those dates.

## Routing records

routing-records.csv lists the Equipment_Approval_Routing__mdt records to create: one per team, keyed on the role name the first build uses as the team, with a fallback approver group, an escalation approver group, and a threshold in the agreed currency. The two teams have different thresholds on purpose so that LIVE-13 can prove the number is read per team. Create the public groups first and record their membership. Fallback group members need access to all requests and must not be able to submit one, so use the IT persona in this exercise and never a manager: a manager with no manager of their own lands in the fallback group and would approve their own request.

The field definitions are in the Custom Metadata Types & Custom Settings chapter; the CSV columns map to them as follows.

| CSV column | Field | Type |
|---|---|---|
| DeveloperName | Record name (DeveloperName) | |
| Team | Team__c | Text; the role name, matched exactly |
| FallbackApproverGroup | Fallback_Approver__c | Text; public group API name |
| EscalationApproverGroup | Escalation_Approver__c | Text; public group API name |
| EscalationThreshold | Escalation_Threshold__c | Number; custom metadata has no Currency type |

Managers have separate roles from their staff, so the sheet includes manager-role records too. Map all example role names to actual roles; configure each manager requester's Manager field. The blank row is a reminder to omit a separate requester role for LIVE-14, including a case where the requester has a Manager populated.

Handle no matching record with a Decision after Get Records, returning routingReady false. Branch to Admin Hold: notify support in a background step, and require the saved routingReady output to equal true before the stage can complete. Expected: Approval Submission In Progress, Equipment Request Awaiting Approval, no manager or Finance work item. Do not use a notification-only End or successful fault path as a hold.

After adding the missing record, an admin with Approval Admin cancels the held submission from Approval Submissions. Under the documented admin Status-edit exception, close the original Equipment Request as Rejected with a routing-failure/replacement reason. Create one new request as the requester and link both request/submission IDs in the incident evidence. The original created-only trigger does not resubmit on an edit.

Test a genuine runtime error separately in T-19. Leave the initial background-only routing stage without a stage fault path and do not swallow the flow error. Verify Approval Submission Error, Equipment Request Awaiting Approval, and the standard error email to the configured support recipient. Restore the working flow and use a linked replacement; an errored orchestration cannot resume.

Move Apply_the_Decision out of Manager_Decision. Manager Result uses Manager_Review outputs for rejection or under-threshold approval; Finance Result uses Finance_Review outputs after escalation. Pass recordId to both, run only one result stage, and notify once. Finance's screen must exclude private justification and use Finance's rejection comments.

Change thresholds only in the sandbox and only for LIVE-15, and restore them afterwards so the other expected results still hold.

## Live scenarios

Day 0 is the date you run the test in the org's agreed context. NeededByDayOffset 7 means seven calendar days after that date; -1 means yesterday for the negative validation test. Record the actual dates used. Expected delivery for waiting stock should be an agreed future date. Use valid equipment values and [CAP-TEST] in the justification, and keep the new Salesforce IDs in your test sheet.

Each live row describes a new request and actions to perform. Do not import it as a completed request. Keep live requests out of the five-key baseline reports; the baseline must read 1720 before and after the change. EstimatedCost values sit deliberately under, between, and over the two team thresholds. For LIVE-17, restore OPS_ROUTING to 1000 and submit a request for exactly 1000; manager approval must complete it without a Finance work item. Restore the test user's original Manager after the no-manager check. An elapsed-time ageing test remains Not run until the threshold has actually been observed.

LIVE-16 records what happens to an approval already awaiting a manager when the new version activates. The existing submission stays on its original version; a new request uses the candidate. Record both. During rollback, reactivate the previous version for new submissions, retain dependencies needed by candidate runs, and record which in-flight submissions can finish safely or need cancellation and replacement. Reactivation does not migrate existing work.

## Honest evidence and review

For each test, record who ran it, their effective permissions, record IDs, expected and actual results, date, and a private evidence reference. Use Pass, Gap or Not run. A written plan does not demonstrate a deployed release. A single identity cannot prove separation between two record owners. No real user review means the review is labelled self-review.

The original holiday-aware ageing requirement is carried forward as a known limitation; this change does not touch it. Record it in the decision log with an owner and next action rather than fixing it inside this change. Do not turn accepted limitations or missing environments into passed tests. Complete the capstone only against the agreed scope across all eight rubric capabilities, with required checks actually run.

Keep credentials and access tokens out of the pack. Redact identifying information before sharing portfolio examples. No learner results are supplied by JamForce.