How to Create the First AMC Job for an Asset
A simple, step-by-step guide (FieldAx on Salesforce)
Step 1: Start from the Case (if there is one)
Usually, an AMC job starts from a Case that a customer has already raised. This is the original request.
For the very first AMC job, you will notice that the “Create New Job” button on the Case does not work — Salesforce blocks it on purpose. This is expected. The first job for a new AMC has to be created through a Service Plan instead, which is what the rest of this guide walks through.
The original Case, before any AMC job is created.
Step 2: Create a Service Plan
Go to the Service Plan object and create a new Service Plan. Fill in the customer, dates, and location, and make sure the Status is set to Active — a Service Plan that isn’t Active cannot be used to schedule jobs.
Creating a new Service Plan and setting it to Active.
The same Service Plan form, filled in with Type = AMC.
Step 3: Set How Often the Next Job Should Repeat
On the same Service Plan, set the Scheduling Method to “Last Planned Date”, the Frequency to “Schedule for Days”, and enter the number of Days. This tells the system how many days after a job is completed it should automatically create the next preventive maintenance job.
For example, entering 90 in the Days field means: once the first job is completed, the system will automatically create the next job 90 days later.
Service Plan saved successfully. Notice “Systems Included (0)” and “Jobs (0)” — nothing has been linked yet.
Step 4: Add the Installed System (Asset) to the Service Plan
Under the Service Plan, go to the “Systems Included” related list and add the installed system this AMC covers. Only one installed system should be linked per Service Plan.
Adding the installed system (e.g. “Dicing machine”) under Systems Included.
The Service Plan now shows Systems Included (1). The “Schedule Job” button is now available.
Step 5: Schedule the Job
Click the “Schedule Job” button on the Service Plan. Fill in the job details — set the Job Category to “Service” and the Job Type to “AMC”, along with all the other usual job details (customer, date, time, and so on).
The Schedule Job form — Job Category = Service, Job Type = AMC Service.
On the next screen, select the installed system for this job (the one you linked in Step 4), then save.
Selecting the installed system while scheduling the job.
Step 6: Link the Job Back to the Original Case
Once the job is created, open it and click on “Source Case” to associate it with the case that was raised earlier. This links the two records together — the job will now also appear on that Case.
The new job, created from the Service Plan (Source Case is still empty).
The job now shows the linked Source Case.
Step 7: Work the Job as Usual
From here, follow the normal job process:
- Click Dispatch to assign a Service Engineer and a scheduled time.
- Carry out the visit and complete the checklist.
- Sign off the service report and mark the job as Complete.
Dispatching the job to a Service Engineer.
The job is marked complete and the service report is saved.
Step 8: The Next Job Is Created Automatically
Once the job is com
pleted, the system automatically creates a new job on the same Service Plan for the same installed system, scheduled after the number of days you set in Step 3 (in this example, 90 days later). You don’t need to create it manually.
The Service Plan now shows Jobs (2) — the completed job and the new job auto-created 90 days later.
Note: Only the very first job needs to be set up this way, through the Service Plan. After that, the cycle repeats on its own — complete a job, and the next one is scheduled automatically.
One More Thing: Creating Extra Jobs Later
If you ever need an additional, unscheduled visit for the same preventive maintenance (the same Service Plan) — for example, an extra breakdown call in between the regular 90-day visits — you don’t need to go through the Service Plan again.
For that, simply go to the Case and use the “Create New Job” button directly. This works fine for extra, one-off jobs.
Only the very first job of a new AMC needs to be scheduled through the Service Plan’s “Schedule Job” button. This is what sets up the automation correctly, so that every future job continues to auto-generate on schedule.
Deployment checklist for AMC 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 AMC :
- 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 |
|
|
| 2 | Record Trigger flow | job_Before_Create_and_Update,
Job_After_create_and_update, Assignment_After_create_update, Case Escalation Email Notification Alert Flow Validate Job Before Escalation Schedule Job For Service Plan
|
||
| 3 | Buttons | Add_Comment – Job On_the_Go_Part_New – Job Schedule Job – Service Plan |
||
| 4 | Validation Rule | Enforce_Case_Status_Sequence – Case Enforce_AMC_Job_Type_For_Service_Plan –Job, Enforce_Job_Status_Sequence – Job Primary_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 | ||
| 8 | Duplicate Rule | Prevent Duplicate Installed System Names | ||
| 9 | Static Resource | GMSLogo | ||
| 10 | App | FieldAx | ||
| 11 | Custom fields | Case object:
Display_AMC_Notes__c , Total_Case_Working_Days__c , ServicePlanHasJob__c , Internal_Comments__c , Installed_System__c , Case_job_Start_DateandTime__c , Case_job_End_DateandTime__c , Case_Handlers__c , Installed system object End_user__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
Installed_System__c, Job_Item_Installed_System__c, Job (fax__Job__c ): Total_Working_Days__c, PO_No__c, PO_Date__c, Job_Start_DateandTime__c, Job_End_DateandTime__c, Internal_Comment__c, Customer_Shipping_Address__c, Customer__c, Case_Internal_Comments__c, Case_Header__c, Case_Handler__c, Case_Description__c |
||
| 12 | LWC | JobRequiredPartsLwc | ||
| 13 | Custom Object | Job Required Part (On_the_Go_Part__c) | ||
| 14 | Tab | On_the_Go_Part__c |
- 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.
|
||
| 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.
|
||




