Overview
This guide walks through how a new equipment installation is recorded and tracked in FieldAx, from the moment an installation request is logged through to job completion. The process follows three stages:
- Create a Case — log the request; for new equipment installation, the Installed System (Asset) is created and linked right here, while for a Service request the existing Installed System is simply selected from the lookup
- Create a Job — once the Case reaches the Job Execution stage, generate a Job directly from the Case (one Job per Case)
- Assign, Execute & Complete the Job — dispatch the engineer, track progress, and close out the installation
Every installation is captured against the Installed System (Asset) record, which becomes the single source of truth for that equipment’s entire service history — installation, future service visits, and AMC visits.
Case status and Job status are two separate, independent flows. The Case flow (Initiated → Internal Review → Principal Review → Job Execution → Escalation → Closed) tracks the request through internal review, while the Job flow (Queued → Assigned → Accepted → Evaluation → OEM Support → Job Execution → Completed) tracks execution once a Job exists. The two are not auto-synced — each is updated on its own record. This applies to Installation, Service, and AMC alike.
Figure 1: Installation Flow — end-to-end summary
STEP 1: Create a Case
When a customer request for a new equipment installation comes in, the first record created in FieldAx is a Case. The Case captures the customer, contact, and request details, and tracks the internal review process before work begins.
Key fields captured when logging a new Case:
| Field | Description |
| Account Name / Contact Name | The customer account and contact raising the request |
| GMS Reported Date & Time | When the request was reported to GMS |
| Case Origin | How the request came in — e.g. Email, Phone, WhatsApp |
| Installed System | The equipment the request relates to (if already on record) |
| Status | Defaults to Initiated |
| Priority | Low / Medium / High |
| Case Handlers | Service engineer(s) assigned to handle the case |
| Case Title / Description | A short title and description of the request |
Figure 2: New Case form
Once saved, the Case moves through the following stages:
- Initiated — the case is logged
- Internal Review — the request is reviewed internally
- Principal Review — consulted with the OEM/Principal if required; this step is optional and can be skipped, moving the Case directly to Job Execution
- Job Execution — work is underway; the Create New Job button becomes available only once the Case reaches this stage (applies to Installation, Service, and AMC), and since one Case can have only one Job, the button is not available again once a Job exists
- Escalation — used only if the case is delayed beyond the expected timeline
- Closed — the case is closed once the team confirms the linked Job is completed and signed off; this is a separate step on the Case, not an automatic update
1.1 New equipment? Create the Installed System (Asset) here
If the Case is for the installation of new equipment, the Installed System (Asset) is created and linked directly on the Case using the Installed System lookup field — the equipment record doesn’t wait for the Job to exist. If the Case relates to equipment already on record, the existing Installed System is simply selected instead.
The following details are captured for each Installed System:
| Field | Description |
| Serial Number | Unique serial number of the equipment |
| Product | The product/equipment model being installed |
| Model | Equipment model reference |
| Installation Date | Date the equipment was installed |
| Location | Site/location where the equipment is installed |
| End User | The end customer using the equipment |
| Competitor (if any) | Notes if the equipment is a competitor’s asset being serviced |
| Manufacturer / Principal / Make | The OEM or principal company |
| Year of Manufacture | Manufacturing year of the equipment |
| Warranty Start / End Date | Warranty coverage period |
Because the Installed System is linked at the Case, the Job created from that Case automatically inherits the same Installed System — and every future visit against that equipment (service calls, AMC visits) rolls up under the same Asset record, giving a complete history of how many times an engineer has attended to it and how much time has been spent.
1.2 Service request? Select the existing Installed System instead
This same Case form is used for Service jobs — the only difference is in how the Installed System field is handled. Instead of creating a new record, the engineer starts typing in the Installed System lookup and searches for the equipment already on record; recently viewed systems appear automatically to speed up selection.
2a: Service Case — selecting an existing Installed System from the lookup instead of creating a new one
Once the existing Installed System is selected, everything downstream works exactly the same way as an installation — the Job created from this Case inherits the selected Installed System, and the visit rolls up into that equipment’s existing service history alongside its installation and any prior AMC or service visits. Only Job Category and Job Type change to reflect Service rather than Installation.
STEP 2: Create a Job
Once the Case reaches the Job Execution stage, the Create New Job button becomes available on the Case — this applies whether the request is Installation, Service, or AMC. Clicking it opens a short form to capture the job scheduling details, and the resulting Job is automatically linked back to the Case. Each Case can have only one Job, so the button is no longer shown once a Job has been created against it.
- Job Category — e.g. Installation
- Job Type — e.g. Installation
- Planned Job Date & Time — when the installation is scheduled
- Urgency — Normal, High, or Critical
Figure 3: Create New Job — quick action from the Case
Once created, the Job carries forward the Customer, Installed System, and Source Case, and starts at status Queued. It also tracks Job Details (Job Description, Job Detail, Message to Engineer) and a Job Summary section (Engineer Completion Notes, Internal Comment, Measurements) that gets filled in as the work progresses.
Figure 4: New Job record — status Queued, linked to the Source Case
STEP 3: Assign, Execute & Complete the Job
With the Job created and the Installed System already linked, the remaining work happens on the Job record itself — dispatching to an engineer, tracking day-wise progress, completing the sign-off checklist, and closing the job.
3.1 Dispatch and schedule the engineer
From the Job record’s action menu, select Dispatch to open the scheduling view and assign an engineer against the planned date and time.
Figure 5: Job actions — Dispatch, Add Parts, Sign-Off Checklist, Consume Parts, Attach Photos, Complete
Figure 6: Quick Schedule — engineer assigned against the planned job date
Once scheduled, the Job status moves from Queued to Assigned.
3.2 Record day-wise progress
For installations that span more than a single visit, comments can be added to the Job at any point using Add Comments. Each entry is automatically timestamped and appended, building a running, date-wise log of what was done.
Figure 7: Add Comments — logging a site visit update
Figure 8: Internal Comment log — entries are stamped with user and date/time
3.3 Complete the sign-off checklist
Before closing the job, the engineer completes the Installation checklist covering functional, electrical, safety, and training items, and can capture any pending issues in the notes field.
Figure 9: Installation Sign-Off Checklist
3.4 Generate the Service Report and capture sign-off
A Service Report can be generated and saved to the Job at any point in progress — not only at the end. This lets the engineer save a report after each day’s visit, building a day-wise record on the Job, right through to the final version.
- Generate the Service Report and select Save PDF to Job to attach it to the Job record
- This can be repeated daily for multi-day installations, so each day’s report is saved against the Job
- On the final visit, the Engineer Signature (and customer signature, where applicable) is captured digitally
- Once the signature is captured, the screen confirms Ready to Complete Job
Figure 10: Service Report saved to Job, with digital signature captured
3.5 Mark the Job complete
With the signed-off Service Report in place, select Complete from the Job actions menu. This is the final action that closes out the job.
Figure 11: Complete — final action on the Job actions menu
- Selecting Complete Job marks the Job as completed in the system
- The Installed System (Asset) status is updated to Active, making it available for future Service and AMC jobs
- Job status is tracked and updated independently on the Job record — it does not automatically change the linked Case’s status, since the Case and Job flows run separately
- The Case is then moved to Closed as a separate step, once the team confirms the Job is complete and customer sign-off has been captured
The Job status flow runs independently of the Case status flow: Queued → Assigned → Accepted → Evaluation → OEM Support → Job Execution → Completed. Each stage is tracked and can be viewed on the Job record as work progresses. OEM Support is optional and can be skipped. If a Job is not closed within 7 days, it is automatically escalated. This flow applies the same way for Installation, Service, and AMC jobs.
Summary
The installation process in FieldAx follows a simple, linear flow:
- Case created → installation request logged; for new equipment, the Installed System (Asset) is created and linked right on the Case
- Job created → once the Case reaches Job Execution, a Job is generated from the Case, linked to it as the Source Case and inheriting the same Installed System — one Job per Case
- Job assigned, executed, and completed → engineer dispatched, progress logged day-wise, checklist signed off, Service Report saved to the Job (daily, if needed) with final digital sign-off, Asset activated
- Case and Job status flows run independently → the Case flow and Job flow are tracked separately (Job flow includes optional OEM Support and 7-day auto-escalation if not closed), with the Case moved to Closed once the team confirms the Job is complete and customer sign-off is captured
Deployment checklist for Service flow:
Schedule:
| Start Date | Time |
| 11 – 09 – 2026 | Start time: 9:30 AM |
| 15 – 09 -2026 | End time: 6:30 PM |
*Disclaimer: The deployment timeline is subject to change in case of unforeseen bugs, technical issues, or requirement changes.
COMPONENTS FOR SERVICE:
- Source Control Update Completed: Yes/No
- Data Backup: Not Applicable
- Code Coverage: / Applicable
- Code Review Completed: Yes/No
- Deployment Method:
✔ Changeset
❑ Salesforce CLI
❑ Ant Migration Tool
❑ Manual Record Creation/ Updation
- Deployment Sequence
| Step | Component Type | Component Name | Comments | |
| 1 | Screen Flow | Add_Job_Comment,
New_Job_Creation_from_Case |
|
|
| 2 | Record Trigger flow | job_Before_Create_and_Update,
Job_After_create_and_update, Assignment_After_create_update,
|
||
| 3 | Buttons | New_Job_Create – Case object,
Add_Comment – Job |
||
| 4 | Validation Rule | Enforce_Case_Status_Sequence – Case Enforce_Job_Status_Sequence – JobPrimary_System_Required_When_Assigned –Job, Require_Queued_Status_For_New_Record – Job, Primary_System_is_Not_valid – Job, |
||
| 5 | Matching Rule | Installed_System_Matching_Rule_Updated | ||
| 6 | Duplicate Rule | Prevent Duplicate Installed System Names | ||
| 11 | Custom fields | Job object – Customer__c,
Equipment__c, Locations__c, MEASUREMENTS__c, Warranty_End_Date__c, Warranty_Start_Date__c, Warranty_Status__c, Year_of_Manufacture__c, Serial_Number__c, Internal_Comment__c, Case_Handler__c, Job_End_DateandTime__c, Job_Start_DateandTime__c, Total_Working_Days__c,
Installed system object –(fax__Installed_System__c)- Installation_Date__c, Location__c, Manifacture__c, Model__c, Product__c, Serial_Number__c, Warranty_End_Date__c, Warranty_Start_Date__c, Year_of_Manufacture__c, End_user__c Site_Contact_Email__c , Site_Contact_Name__c , Site_Contact_Phone__c, PO_Date__c , PO_No__c Installed_System__c Job__c Job_Item_Id__c Part_Number__c Product_Name__c Quantity_Newly_Added__c Quantity__c Sourced_From__c System_Name__c Unit_Price__c |
||
| 12 | LWC | JobRequiredPartsLwc | ||
| 13 | Custom Object | Job Required Part (On_the_Go_Part__c) | ||
| 14 | Tab | On_the_Go_Part__c | ||
| 15 | Apex | CaseJobExistenceController,
CaseJobExistenceControllerTest |
- Post-Deployment Steps
o Not Applicable
| Post Deployment Checklist | ||
| Checklist Items | Completed/Not Applicable/Skipped | Comments |
| Apex Classes and Triggers: | ||
| 1. Test Execution: Run critical test classes to ensure the basic functionality of new or updated Apex code. | ||
| 2. Monitoring: Set up debug logs and basic monitoring to track performance and errors. | ||
| 3. Documentation: Update developer documentation for deployed Apex classes and triggers. | ||
| Workflows, Processes, and Flows: | ||
| 1. Activation and Validation: Activate critical workflows, processes, or flows and verify their behavior. | ||
| 2. Basic Integration Validation: Confirm basic functionality of process automation involving external systems. | ||
| 3. Error Handling: Ensure basic error handling is in place for critical workflows and processes. | ||
| 4. Flow Versions Check: Make sure only the latest 2 versions of flows exist in Prod. (Delete other versions of the flow.) | ||
| Lightning Components and Visualforce Pages: | ||
| 1. Accessibility Verification: Confirm that UI components are accessible and functional. | ||
| 2. Basic Functionality Testing: Manually verify critical functions on Lightning components and Visualforce pages. | ||
| 3. Documentation: Ensure user documentation reflects changes related to UI components. | ||
| Reports and Dashboards: | ||
|
1. Validation: Verify the accuracy of critical reports and dashboards in the production environment.
|
||
|
2. Permissions: Review and set permissions for critical reports and dashboards.
|
||
|
3. Documentation: Update user documentation for key reports and dashboards.
|
||
| Data Migration and Integration: | ||
|
1. Data Validation: Validate critical data migrated or integrated post-deployment.
|
||
|
2. Basic Integration Testing: Confirm basic data flow between Salesforce and integrated systems.
|
||
|
3. Backup and Recovery: Ensure basic data backups and recovery procedures are in place.
|
||
| Security and Permissions: | ||
|
1. Permission Sets and Profiles: Review and update permissions for new or modified components.
|
||
|
2. Security Review: Conduct basic security review for new deployments.
|
||
|
3. User Access: Validate user access permissions for critical functionalities.
|
||
| General Post-Deployment Tasks: | ||
|
1. User Communication: Notify users or stakeholders about deployment and changes.
|
||
2. Documentation Updates: Update system
3. documentation and release notes.
|
||
4. Performance Monitoring: Set up basic performance monitoring and observe initial usage. |
||
5. Issue Tracking: Monitor for any critical issues and address them promptly. |
||
| Field: | ||
|
1. Ensure Set Field-Level Security
2. Ensure the Field is added to the Page Layout
3 .Ensure the Field is added Lightning Record Page
|
||
| Page Layout: | ||
1. Ensure if page layout assigned any record type. 2. Ensure if page layout is assigned any profile.
|
||
| Lightning Record Page: | ||
1. Ensure that there is a dynamic form, then check the Lightning Record Page works as expected. |
|
|
| Custom Settings | ||
1. Formula Fields: If you have formula fields referencing custom settings: A. Test that calculations are correct, reflecting any modified custom settings values.
B. Ensure there are no errors in the formulas due to changed field names or data types within the settings.
|
||
2. Apex Code: For code that depends on custom settings: A. Run unit tests to confirm code logic behaves properly with the new settings.
|
|
|
| 3. Validation Rules: If you use custom settings in validation rules:
|
||
| 4. Data Caching considerations | ||
| Custom Metadata (Custom Metadata Records) : | ||
| 1. Verify that any new or updated custom metadata records contain the correct values.
A. Apex Code: If you have Apex code referencing custom metadata types:
B. Conduct rigorous unit testing of any code dependent on custom metadata.
C. Pay particular attention to the code that queries or processes these records. |
||
| 2. Relationships: If you’ve established relationships between custom metadata types:
A. Verify that relationships properly link records.
B. Write test scenarios to confirm that code interacting with related custom metadata types behaves accordingly.
|
||












