Deployment Record Change Procedure

Deployment Record Change Procedure

Incomplete Version:
This is an initial version of the procedure. Additional process maps, examples, and detailed approval requirements will be added in future updates.

Last Updated: 10/17/2025

1. Overview

This procedure applies to any changes made to an existing deployment record within EMS. Changes may originate from one of two sources:

1. Mobilization-Initiated Corrections

   • These are changes identified and made by Mobilization Leaders or Staff to correct inaccurate information originally entered.
   • No additional approval or documentation is required before making the correction.

2. Requests from the RFM Portal

   • When a change request is submitted through the RFM Portal, follow the RFM Approval Verification Process (see Related Documents) before making any edits in EMS.
   • Once verified, proceed with the steps below.

---

2. Accessing the Greyshirt Deployment Record

1. Log into EMS and locate the Greyshirt’s profile.
   • If working from an RFM Portal request, click the Greyshirt’s name in the request to be taken directly to their profile.
2. Within the profile, open the Deployments tab.
3. Locate the deployment that requires the change.
   • If the request originated from the RFM Portal, the deployment details (such as operation name, start date, or end date) will be available in the RFM metadata.
   • Use these details to confirm that the correct deployment record has been selected.

---

3. Making the Change

1. Open the deployment record for editing.
2. Review the details to ensure that the correct record is being modified.
3. Make only the following types of changes:
   • Role
   • Start Date
   • End Date
   • Resource Mobilization Status
   • Rally Point, Billet, or FOB

Callout:
If the change involves a Greyshirt who is also a flier but there is no associated flight request, the Mobilization Leader should engage Mobilization Staff before making any updates. This ensures other connected resources are reviewed before proceeding.

4. After the deployment record is saved in EMS using the Save button in the upper left corner, wait a few seconds for the page to refresh automatically.
   • If the page does not refresh, manually refresh it.
   • Confirm that the updated deployment dates are reflected correctly if any date changes were made.

---

4. Date Change Guidance and Workflow

Changes to deployment dates are among the most common updates. The table below provides guidance on how to handle specific date change types:

Change Type	Description	Example Scenario	Action
Early Departure	Departure date moves earlier than planned.	Greyshirt leaves before end of operation due to personal or operational need.	Update the End Date and verify travel arrangements if applicable.
Extension	Deployment is extended beyond the original end date.	Greyshirt remains longer to support extended mission needs.	Update the End Date and verify continued lodging or role coverage.
Arrival Adjustment	Start date is changed.	Correction of a late or early arrival date.	Update the Start Date and ensure alignment with actual arrival.
Historic Correction	We do not make historical corrections at this time. Engage Mobilization Staff for exceptions.	Correction for post-operation reporting accuracy.	Update both Start Date and End Date as required.

---

4.1 Impact on Bookable Resource Bookings (BRBs)

Bookable Resource Bookings (BRBs) define a Greyshirt’s actual scheduled deployment days and drive what the operation sees in EMS.

• The Deployment Dates field is a visual indicator that reflects the overall range of BRBs.
• This field is automatically updated whenever the Start Date or End Date of the deployment is changed, as those actions create or remove BRBs.
• The Deployment Dates field does not update if BRBs are manually deleted or adjusted outside of that process.
• BRBs should never be manually added or removed. All changes must occur through valid Start or End Date updates.

Early Departure

• When the End Date is changed to an earlier date:
  • All BRBs after the new End Date are automatically removed.
  • Any gaps or breaks between existing BRBs remain unchanged.
  • The Deployment Dates field updates automatically to show the new date range.

Extension

• When the End Date is changed to a later date:
  • The system automatically creates any missing BRBs between the Start and End Dates.
  • This can unintentionally fill in gaps where the Greyshirt is not actually attending.

When to Create a New Deployment Record

If extending a deployment would add BRBs for future days the Greyshirt will not actually attend, do not extend the existing record.

Instead, create a new deployment record (or multiple records if there will be multiple gaps) and direct dispatch the Greyshirt following the Direct Dispatch Process (see Related Documents).

Examples

Scenario	System Behavior	Action
Early Departure (shortening range)	BRBs after new End Date are removed; gaps preserved.	Proceed with End Date change.
Continuous Extension	New BRBs created for all new days in sequence.	Proceed with End Date change.
Extension with future gaps (unattended days)	New BRBs created for every missing day between Start and new End Date.	Create new deployment record(s) and direct dispatch.
Past gap correction	BRBs added for missed days in the past.	Proceed with End Date change.

---

5. Completion

Once the change is made:

1. Verify that the record now reflects the correct information.
2. Close or mark the RFM request as complete (if applicable).

---

6. Future Additions

This procedure will be expanded to include:

• Specific process maps and visual workflows for complex change types.
• Integration with automated notifications and reporting.
• Cross-references to the final RFM Approval Verification Process once completed.