**National Dispatch Efficiency Working Group**

**Interagency Standards for the ROSS Operations Guide (ISROG)**

**Standard Business Practices for Using ROSS within the\
Interagency Business Community**

**March 22, 2007**

# Contents

[Incident Screen 2](#incident-screen)

[Incident Resources Screen 3](#incident-resources-screen)

[New Initial Report or Incident Screen
4](#new-initial-report-or-incident-screen)

[Merge Incidents Screen 8](#merge-incidents-screen)

[Multi-Place Screen 8](#multi-place-screen)

[New Request Screen 8](#new-request-screen)

[Pending Request Screen 10](#pending-request-screen)

[Request Status Screen 11](#request-status-screen)

[Resource Status Screen 14](#resource-status-screen)

[Resource Item Screen 15](#resource-item-screen)

[Roster Screen 15](#roster-screen)

[Tactical Aviation Screen 16](#tactical-aviation-screen)

[Travel Screen 16](#travel-screen)

# Incident Screen

**Navigation Instructions.** To display reporting directions or
instructions within the Description Location (block 5) of the printed
resource order, within the Incident Screen select the "locations tab",
and then from the "Locations Use" pull down menu select "Command Post".
Within the Navigations Instructions field enter information to be
displayed on the resource order form. Include road directions to the
delivery point or reporting point. If the deliver to point is the
incident, type the navigation instructions within the Directions tab of
the incident screen.

**Financial Codes.** Post valid financial codes on the Incident screen
under the Financial Codes tab. Inactivate financial codes when no longer
used or needed.

Always include the **Forest Service Override Code** when using a Forest
Service financial code.

DO NOT enter Financial Codes on the New Incident screen in the Office
Reference Number box.

-   Only the dispatch center that created the incident may assign
    financial codes. If you have filled a request and as part of this
    activity assigned a specific agency financial code or are in need of
    a financial code, contact the ordering office through established
    ordering channels and request them to enter the financial code in
    ROSS.

**Frequencies**. Identify and select frequencies before ordering the
resource that needs them. Identify and select both air‑to‑air and
air‑to‑ground frequencies before placing Aircraft orders.

When frequencies are added or removed from an incident, you must update
and revise this information immediately. Large incidents will identify
frequencies within the Incident Action Plan (IAP). It is recommended
that the dispatch unit supporting a large fire receive the IAP on a
regular basis.

**Airports.** Identify all possible jet ports that mobilizing resources
will use when flying commercially. Any new request created that is
expected to be filled with non-local resources must have the jet port
identified. Jet ports must be identified within the Airports tab in the
Incident Screen.

**Contacts.** Enter new contact information specific to the incident
under the Contacts tab. All contacts located within the Contacts tab
will be displayed on a printed resource order within the Incident Base /
Phone Number (block 8) field. Delete any contacts that should not to be
displayed on a printed resource order.

For example, the host agency creates an expanded dispatch organization
for an incident, a new contact name with the appropriate phone number
including area code (Arbuckle Expanded 1-999-999-9999) will be created
within the Contacts tab and all old contact information is deleted. The
expanded dispatch contact will be used until the expanded organization
is released. When expanded is released, the contact should be deleted
and the normal contact name and phone number (Arbuckle Dispatch) and
telephone number will be re-created for the duration of the incident.

**Documentation.** Enter any important documentation pertaining to a
specific request on the on the New Request screen.

-   You may view user documentation entered on this screen, but it will
    not display on the printed resource order or on reports.

# Incident Resources Screen

Refer to the [Request Status Screen]{.underline} section for the
Interagency Standards required of Support Requests.

> **Working with Subordinate requests**. ROSS assigns subordinate
> request numbers to the resources that are filling positions on an
> assignment roster. Members of an overhead team, fire crew, or an
> engine may be part of a subordinate request.
>
> For example, the parent request for a Type 6 Engine is request number
> "E-16" the subordinate crew members on the assignment roster would be
> numbered, "E-16.1," "E-16.2," "E-16.3," and so on.
>
> When adding subordinate requests:

-   You can add a subordinate request only to a filled configuration
    request.

-   The sending (filling) unit can add a subordinate request only when
    the resource used to fill the parent request is "Reserved" or "Mob
    in Route."

-   The receiving unit can add a subordinate request only when the
    resource used to fill the parent request is status as "Mob in Route"
    or "At Incident."

-   You cannot select a Preorder when adding a subordinate request.

> To add a subordinate request to a filled configuration request
>
> 1\. On the Request Status screen, search for and then click to select
> the filled configuration request of your choice.
>
> 2\. Click the Action button, and then click Add Subordinate Request.
>
> 3\. On the Create Subordinate Request dialog box on the Catalog tab,
> search for and then click to select the catalog item of your choice.
>
> 4\. Click the Request tab, and then complete all appropriate and
> requested boxes to complete the subordinate request.
>
> 5\. If the new subordinate request is being added to a parent request
> for a local incident, which was place to and filled by another
> organization, click to select one of the following options under
> Select Placement.
>
> \- to place the subordinate request with the organization that filled
> the parent request, click Place Directly with Filling Organization.
>
> \- to add the subordinate request to the Pending Request screen, click
> Place/Fill Locally (via Pending Request).
>
> \- to view information about the filling unit, click the View button.
>
> 6\. When finished, click the Create Request button.

**Release and Reassign actions**. Be sure to complete all travel
information correctly. You must use the actual date the action occurred.
If a resource was released several days prior the ROSS release or
reassignment, use the actual date the resource left the incident.

Refer to the [Travel Screen]{.underline} section for the Interagency
Standards required of Travel.

**Add Documentation action** for [Emergency Releases]{.underline}. All
dispatch personnel associated with the transmittal and the verification
that an emergency message was placed and received by the intended
recipient will be documented. Use clear, simple text and avoid acronyms
and abbreviations. Discretion should be applied.

-   Do not document any information that is confidential and/or
    personal.

-   Limit documentation to pertinent information concerning the
    emergency release; identify all contacts for demobilization from
    departure point to arrival point.

-   Document that verification of information was passed and received by
    affected parties.

# New Initial Report or Incident Screen

**Internal Incidents.** Select except when dispatching for a unit that
is external or status‑only.

**Incident Type.** There are 43 types of incidents. Select the
appropriate type of incident. Incident types that are described below
have standardized uses; all others do not.

-   **"**Other Support" will be selected when requesting resources to
    work directly for the host agency responsible for supporting an
    actual incident. Other support resources are expected to remain on
    their original order for the commitment duration and are not
    normally reassigned. Examples of support resources include
    dispatchers, cache workers, ramp personnel, and other positions
    described within Chapter 30 of the National Interagency Mobilization
    Guide, Incident Support Organization (ISO). Support resources
    perform duties associated with the host agency and are not
    associated directly with the incidents being supported by the host
    agency. For specific information on the ISO, see
    [http://www.nifc.gov/nicc/mobguide/Chapter_30.pdf]{.underline}

-   "Preparedness/Preposition" will be selected when requesting
    resources that, once arrived, will be locally available for wildfire
    reassignments during the commitment duration.

-   "Training -- Classroom," "OJT," "Proficiency," and "Simulation" may
    be used for resources available locally and within the host agencies
    Geographic Area. Requests for NIRSC radio items in support of these
    incidents will be placed through NICC.

    -   It is not a national requirement to create an incident to
        support mobilization of casual employed personnel (AD) for
        agency training purposes.

    -   NICC will not process requests for overhead resources associated
        with "Training" incidents; this includes students and/or
        instructors.

**Incident Name.** Incidents established in ROSS should be appropriately
named. When left blank, the incident number will default to the incident
name. It is recommended to appropriately name each incident before
placing requests outside of the local host agency or/or the ordering
unit jurisdiction. Below are recommendations and examples as for naming
incidents within ROSS.

**When naming a "Wildland Fire" incident** within ROSS, it is
recommended that a local geographic feature be included within the
incident name. There is no requirement to include the word "Fire" within
the incident name.

> [Example #1]{.underline} for the naming of a "Wildland Fire" incident;
> the Vale District located in Oregon (OR-VAD) requires crews for an
> escaped fire near Castle Rock. Utilize the category "Wildland Fire"
> for the incident type and by following the recommended incident naming
> convention, an appropriate name may be [Castle Rock.]{.underline}

**When naming other types of incidents** that are available within ROSS
such as "Flooding" or "Hurricane/Typhoon" or "Fire -- Prescribed", it is
recommended to use the event or activities pre-existing name if
established within the incident name created within ROSS.

> [Example]{.underline} for the naming of a "Flood" incident; the
> Fairbanks Area Forestry office in Alaska (AK-FAS) requires a hand crew
> for the placement sand bags along the Tanana River. Utilize the
> category "Flood" for the incident type and when adhering to the
> recommended incident naming convention, an appropriate name may be
> [Tanana River Flood -- January 2007]{.underline}.

**When naming an "Other Support" incident** (off incident support order)
within ROSS, the incident name should include the word "Support and/or
Severity" in the incident name when ordering resources that are
mobilized in response to an agency's approved severity request. If a
specific incident is being supported, the incident name would also be
included.

> [Example #1]{.underline} for the naming of an "Other Support"
> incident; the Boise Interagency Logistics Center located in Idaho
> (ID-BDC) requires additional dispatch personnel to help with predicted
> high volume fire activity. Utilize the category "Other Support" for
> the incident type and when adhering to the recommended incident naming
> convention, an appropriate incident name may be [BDC Dispatch Support
> -- IA Multiple Fires]{.underline}.
>
> [Example #2]{.underline} for the naming of an "Other Support"
> incident; the Boise District Office located in Idaho (ID-BOD) requires
> a fixed wing aircraft and associated personnel to provide detection
> and mapping of potential fires. Costs are being funded from a BLM
> appropriated fund source. Utilize the category "Other Support" for the
> incident type and when adhering to the recommended incident naming
> convention, an appropriate incident name may be [BOD Severity /
> Aviation Support - 2007]{.underline}.
>
> [Example #3]{.underline} for the naming of an "Other Support"
> incident; the fire cache managed by the Boise National Forest located
> in Idaho (ID-BOF) requires a fork lift to assist with the large volume
> of fire supplies being ordered by the Lowman fire. Utilize the
> category "Other Support" for the incident type and when adhering to
> the recommended incident naming convention, an appropriate incident
> name may be [Lowman -- Cache Support]{.underline}.
>
> [Example #4]{.underline} for the naming of an "Other Support" incident
> associated with a hurricane; the Everglades National Park located in
> Florida (FL-EVP) requires a logistics team to support hand crews and
> overhead assigned to provide facility cleanup resulting from high
> winds generated by Hurricane Arbuckle. Utilize the category "Other
> Support" for the incident type and when adhering to the recommended
> incident naming convention, an appropriate incident name may be
> [Hurricane Arbuckle Everglades Support]{.underline}.

**When naming "Preparedness/Preposition" incidents** within ROSS, the
incident name should also include either the word "preparedness" or the
word "preposition" in the incident name when ordering resources that are
mobilized in response to an agency's approved severity request.

> [Example #1]{.underline} for the naming of a
> "Preparedness/Preposition" incident**;** the Boise National Forest in
> Idaho (ID-BOF) requires additional engines be located throughout the
> forest for a predicted high volume of new fires. Utilize the category
> "Preposition/preparedness" for the incident type and when adhering to
> the recommended incident naming convention, an appropriate incident
> name may be [2007 BOF IA Preposition]{.underline}.
>
> [Example #2]{.underline} for the naming of a
> "Preparedness/Preposition" incident**;** the Mendocino National Forest
> in California (CA-MNF) requires a type 1 helicopter and associated
> personnel to be located at the forest helibase for a predicted high
> volume of new fires. Utilize the category "Preposition/preparedness"
> for the incident type and when adhering to the recommended incident
> naming convention, an appropriate incident name may be [Mendocino July
> Aviation Severity]{.underline}.

**Complex.** When creating a complex, [you must manually
append]{.underline} the word "Complex" to the end of the parent incident
name. Select the Complex check box for the incident that becomes a
complex. All other incidents that are related to the parent incident
will automatically have \[CPX\] added to the incident name when they are
associated. Note: You only need to enter "Complex" to the end of the
parent incident name.

**Incident Host.** Identify the incident host by
responsible/jurisdictional agency. The Incident Host is the owner agency
that provides the primary financial code for payment of requested
resources and/or the agency that generates the need for requesting the
resources.

**Location Name.** ROSS defaults to incident name and this displays on
the printed resource order. You may type up to 50 characters to add
additional information.

**Office Reference.** May be used by the unit creating the incident for
internal filing or other internal tracking purposes. It is recommended
that financial code information not be located within the office
reference field.

**Financial Code.** Locate the host agency financial code. If using more
than one financial code from the same agency, identify the primary code
by selecting the default button. DO NOT mix financial codes that are not
similar in intent. All Forest Service financial codes require an
associate override code.

-   [Severity, Suppression, FEMA Financial Codes]{.underline}. - When an
    agency has assigned a financial code to an incident resource order
    with the intent of obligating suppression funds, severity funds,
    Federal Emergency Management Agency (FEMA) disaster funds, or
    similar funding sources, DO NOT permit an additional financial code
    that obligates an agency's budgeted or allocated funds (hard
    dollars).

> Example for Severity, Suppression, and FEMA Financial Codes: An
> incident resource order is created by an agency for the purpose of
> wildland fire fighting using a suppression fund source. Create a new
> incident resource order to identify and obligate the budgeted or
> similar funding. DO NOT assign financial codes associated with
> budgeted (hard dollar) funding sources to the incident.

-   [Agency Budget, Allocated, Hard Dollar Codes]{.underline}. When an
    agency has assigned a financial code to a resource order with the
    intent of obligating budgeted (hard dollars) or allocated funding,
    DO NOT permit an additional financial code that obligates
    suppression funds, severity funds, Federal Emergency Management
    Agency (FEMA) disaster funds, or similar funding sources.

> Example for Agency Budget, Allocated, and Hard Dollar Codes: An
> incident resource order is created by an agency for the purpose of
> insect control using a budgeted (hard dollar) financial code. DO NOT
> assign financial codes associated with a suppression fund source to
> the incident.

**Radio Frequencies.**

Standards for this are being developed.

**Set Air Tactical.**

Standards for this are being developed.

# Merge Incidents Screen

Standards for this screen are being developed.

# Multi-Place Screen

Refer to the [Request Status Screen]{.underline} section for the
Interagency Standards required of Support Requests.

Standards for this screen are being developed.

# New Request Screen

NICC will not process "after-the-fact" new requests for resources that
have been self dispatched or self mobilized to an incident. NICC will
not process "after-the-fact requests that are intended to provide
correction to the length of commitment for a past assignment.

NICC may process "after-the-fact" requests that are intended to correct
an accidental release of a resource by a ROSS user error. Prior to
placing the request, the ordering unit will provide adequate
documentation.

**Need Date/Time.** Enter the appropriate Need Date/Time the resource is
needed. For local initial attack purposes, this is often left blank. If
left blank, the time will default to the moment the new request was
created.

When placing up, DO NOT use the default time. Prior to placing requests
up, verify that the date and time is realistic and, if needed, revise
the date and time.

**Support Request.** After a request is created, the action button will
allow for a support request to be created for the new request. Refer to
the [Request Status Screen]{.underline} section for the Interagency
Standards required of Support Requests.

**Named Requests Only**. Use the Name Request Only field when a name
request is created. NICC will not process any "name requests" if they
are located elsewhere.

-   Prior to placing a Name Request, the incident and ordering unit must
    adhere to the policy and associated criteria as identified within
    Chapter 22 of the National Interagency Mobilization Guide.

> <http://www.nifc.gov/nicc/mobguide/Chapter_20.pdf>

**Deliver To**. All new requests created for the incident that will be
filled with non-local resources must have the commercial jet port
identified in the Deliver To field. Commercial Jet ports must be
identified within the Airports tab on the Incident Screen before they
can be selected from the "deliver to" field.

**Reporting Instructions**. You may select pre-identified information or
you may create new information.

> \- For all NIRSC radio kits and 4390 ICS starter systems, you must
> enter the deliver-to-address in the Reporting Instructions field.
>
> \- Include who the mobilizing resources are to contact. For example*,*
> Bill Fletcher at NICC Dispatch 208-387-5400.

**Special Needs.** Use special needs only to describe information that
is not documented anywhere else. Identify information that is critical
to the resource mobilization, such as the time and physical location of
the team in-briefing for the incident management team.

> \- DO NOT identify named requests in special needs. NICC will not
> process named requests that are identified in the special needs box.
>
> \- DO NOT enter special needs that are listed or specified in another
> ROSS field on this screen.

Information identified in Special Needs:

-   [Use of the THSP position code]{.underline} requires additional
    information be located within the Special Needs field. The ordering
    unit must fully describe all duties to be performed of the THSP
    position prior to placing the THSP request. When appropriate, a GACC
    or NICC can direct an ordering unit to correct and resubmit a THSP
    request as an appropriate Position Code.

    [Only use the THSP position code]{.underline} when there is no other
    appropriate position code available.

-   [NIRSC radio kits and NIRSC ICS Starter Systems]{.underline}. Enter
    the required Bill-to-Address in the Special Needs field for all
    radio kits and ICS Starter Systems prior to placing the requests.

    If the request is for a starter system replacing a prepositioned
    starter system, enter the appropriate FireCode that will be charged
    for the transportation costs. For example*, charge transportation to
    FireCode 1234*.

-   [Resource mobilization information]{.underline}. Identify
    information critical to the resource mobilization such as the time
    and physical location that an incident management team will receive
    the team in-briefing.

-   [Remote Automated Weather Station (RAWS)]{.underline}. When
    requesting a RAWS, identify if a RAWS technician is available
    locally. Include the technicians name and contact information.

-   [Advance Approval Items]{.underline}. Identify any item that must be
    approved in advance of mobilization. This includes rental vehicles,
    agency owned vehicle (AOV), privately owned vehicle (POV), cell
    phones, and/or laptop computers.

-   [Not Approved Items]{.underline}. Include items that are not
    authorized. For example, "rental car is not authorized."

-   [Required Items of High Importance]{.underline}. Identify required
    items such as cell phones, laptop computers, rental cars, personal
    protective equipment (PPE), tools, or lunches. Identify the
    off‑incident location where a helicopter manager (HELM) will meet
    the Call-When-Needed helicopter.

-   [Name or Resource Suggests]{.underline}. Include the official name
    as it is listed in ROSS, the local unit, and appropriate GACC.
    Include the contact telephone number. For overhead personnel,
    identify the agency employment status.

    -   Any dispatch unit within the established ordering chain may fill
        the pending request with a qualified and available resource.

    -   Casual, EFF, or AD hire employees must be identified as such and
        may be requested as a Name or Resource Suggests.

**Configuration Option.**

-   [Engines]{.underline}. All engine requests should be ordered using
    the default "with configuration."

-   [Helicopters]{.underline}. Unless the ordering unit has the
    helicopter manager and module members available locally, all
    helicopters should be ordered using the default "with
    configuration."

# Pending Request Screen

**Support Request.** Refer to the [Request Status Screen]{.underline}
section for the Interagency Standards required of Support Requests.

> **Fill request.** Set ETD/ETA travel when filling the request.

-   [Mode of Travel]{.underline}. *Fill* *Request dialog box*. Identify
    the commercial airline, POV, and other travel details. This field
    should be identical to the Mode of Travel field on the Travel
    screen.

> **Unable to Fill Request (UTF)**. [Use only when your unit has no
> available resources to fill a pending request]{.underline}. **Do not**
> UTF a request if the ordering unit asks for the request to be
> returned. The ordering unit must retrieve the request.

-   [Add Documentation]{.underline} action is mandatory. Enter complete
    documentation before the request is UTF.

> **Cancel UTF Request.** Use [only]{.underline} when there are no
> available resources to fill a pending request. Only the incident's
> designated dispatch office that created the request will utilize the
> "Cancel UTF" function. The "Cancel UTF" function will only be used
> after it is determined that the request is not going to be filled. [Do
> not use the "Cancel UTF" function for a request after it is determined
> that the incident no longer needs the request.]{.underline}

-   [Add Documentation]{.underline} action is mandatory. Enter complete
    documentation before the request is "Cancel UTF" unable to fill
    request UTF. Identify within the request's documentation the reason
    the request is being Cancel UTF.

> **Cancel Request.** Use only when a pending request is no longer
> needed by the incident. Only the incident's designated dispatch office
> that created the request will utilize the "Cancel" function. The
> "Cancel" function will only be used after it is determined that the
> incident no longer needs the request. [Do not use "Cancel Request"
> function for a request that is unable to fill (UTF).]{.underline}

-   [Add Documentation]{.underline} action is mandatory. Enter complete
    documentation before the request is "Cancel". Identify within the
    request's documentation the reason the request is being Cancelled.

> **Fill with Agreement.** Use for resources not in ROSS. These
> resources are only assigned to the individual incident and are not
> part of the permanent ROSS database.

-   [Add Documentation action]{.underline}. *mandatory*. Enter complete
    documentation before completing the fill with agreement action.

# Request Status Screen

**Always document actions of importance that pertain specifically to
resources assigned to an incident.**

> **Cancel Request.** Use only when a pending request is no longer
> needed by the incident. Only the incident's designated dispatch office
> that created the request will utilize the "Cancel" function. The
> "Cancel" function will only be used after it is determined that the
> incident no longer needs the request. [Do not use "Cancel Request"
> function for a request that is unable to fill (UTF).]{.underline}

-   [Add Documentation]{.underline} action is mandatory. Enter complete
    documentation before the request is "Cancel". Identify within the
    request's documentation the reason the request is being Cancelled.

> [To cancel a request that has been placed to another
> unit]{.underline}. The canceling unit must contact, via telephone and
> through the established dispatch ordering chain, the unit where the
> request is currently pending or waiting to be filled and provide
> notice that the request is going to be canceled.

-   [View/Add Documentation action]{.underline}. *mandatory*. Enter
    reason of cancellation and action taken before completing the cancel
    request action. **All affected units must accurately enter
    documentation.**

> [To cancel a request for a National Resource that has been placed to
> another unit.]{.underline} The canceling unit must contact, via
> telephone and through established dispatch ordering chain, the unit
> where the request is currently pending or waiting to be filled and
> provide notice that the request is going to be canceled.

-   If any dispatch unit within the established dispatch ordering chain
    is closed or is unable to process the cancellation request, the
    canceling unit will contact the sending unit directly.

-   [View/Add Documentation action]{.underline}. *mandatory*. Enter
    reason of cancellation and action taken before completing the cancel
    request action. **All affected units must accurately enter
    documentation.**

> [To cancel an already filled request]{.underline}. The canceling unit
> must contact, via telephone through established dispatch ordering
> chain, the sending unit where the request is currently filled.

-   [The canceling unit will contact the sending unit directly, via
    telephone, if any dispatch unit within the established dispatch
    ordering chain is closed or is unable to process the cancellation
    request]{.underline}.

    -   If the assigned resource can be contacted before travel begins,
        the resource will be unfilled and the ordering unit will cancel
        the request.

    -   If the assigned resource has begun travel but the travel has yet
        to start in ROSS, the resource will be unfilled and the ordering
        unit will cancel the request.

    -   If the assigned resource has begun travel in ROSS, the request
        must be released by the requesting dispatch to ensure accurate
        documentation.

        [View/Add Documentation action]{.underline}. Enter the reason of
        cancellation and action taken before completing the cancel
        request action. All affected units must accurately enter
        documentation.

> **Retrieve** Request action. Use only when the order was placed by
> mistake or when a closer resource from another unit becomes available.
> Retrieving a request that has been placed to other locations requires
> various immediate actions.

The retrieving unit must contact, via telephone and through established
ordering channels, the unit where the request is currently pending or
waiting to be filled and provide notice that the request is to be
retrieved.

> Prior to actually retrieving the request, user entered documentation
> is mandatory and must be accurately entered by the retrieving
> dispatcher. Documentation should describe the reason the request is
> being retrieved.
>
> **Support Request.** Support request required for the mobilization of
> crews, equipment and overhead may be created or added by the incident
> dispatch, or by any unit in the ordering or filling chain.
>
> [NICC will not normally process support requests]{.underline} for
> equipment items required for mobilizing and/or the demobilization of
> resources.
>
> [Example #1]{.underline} a low boy trailer is required to transport a
> Type 2 Dozer. The unit filling the Type 2 Dozer will create the
> support request and assign the low boy trailer to transport the Type 2
> Dozer. If the unit filling the Type 2 Dozer is unable to locate a low
> boy trailer, the support order may be placed elsewhere.
>
> [Example #2]{.underline} for a crew being mobilized to a "wildfire"; a
> type 2 crew from Elko, Nevada requires a bus for transporting the crew
> to a Utah incident. The bus should be assigned to a support request
> created by the Elko Field Office (unit filling the crew) and filled
> locally. The support request will not be processed by NICC.
>
> [Example #3]{.underline} for a camp crew being mobilized to a
> "wildfire"; a camp crew from Moab, Utah requires a 10 passenger van
> for transporting the crew to a New Mexico incident. There are no local
> vehicles available. The coordination center in Salt Lake City, Utah
> created the support request and locally hired a van. The support
> request will not be processed by NICC.
>
> [Example #4]{.underline} for a low boy trailer to demobilize a tractor
> plow from a "wildfire"; a a county fire district in Kansas used a
> lowboy trailer to transport a tractor plow resource ordered to an
> incident located in Oklahoma. The lowboy returned to Kansas after
> delivery. During the assignment, the tractor plow was reassigned to
> multiple incidents, and as a result, the county fire district in
> Kansas is unable to create a support request for sending the lowboy
> back to demob the tractor plow. The support request was created by
> local Oklahoma dispatch unit and placed up. NICC will process the
> support request once received from the Southern Area Coordination
> Center.
>
> **Working with Subordinate requests.** ROSS assigns subordinate
> request numbers to the resources that are filling positions on an
> assignment roster. Members of an overhead team, fire crew, or an
> engine may be part of a subordinate request.
>
> For example, the parent request for a Type 6 Engine is request number
> "E-16" the subordinate crew members on the assignment roster would be
> numbered, "E-16.1," "E-16.2," "E-16.3," and so on.
>
> When adding subordinate requests:

-   You can add a subordinate request only to a filled configuration
    request.

-   The sending (filling) unit can add a subordinate request only when
    the resource used to fill the parent request is "Reserved" or "Mob
    in Route."

-   The receiving unit can add a subordinate request only when the
    resource used to fill the parent request is status as "Mob in Route"
    or "At Incident."

-   You cannot select a Preorder when adding a subordinate request.

> **To add a subordinate request to a filled configuration request**
>
> 1\. On the Request Status screen, search for and then click to select
> the filled configuration request of your choice.
>
> 2\. Click the Action button, and then click Add Subordinate Request.
>
> 3\. On the Create Subordinate Request dialog box on the Catalog tab,
> search for and then click to select the catalog item of your choice.
>
> 4\. Click the Request tab, and then complete all appropriate and
> requested boxes to complete the subordinate request.
>
> 5\. If the new subordinate request is being added to a parent request
> for a local incident, which was place to and filled by another
> organization, click to select one of the following options under
> **Select Placement**.
>
> \- to place the subordinate request with the organization that filled
> the parent request, click Place Directly with Filling Organization.
>
> \- to add the subordinate request to the Pending Request screen, click
> Place/Fill Locally (via Pending Request).
>
> \- to view information about the filling unit, click the View button.
>
> 6\. When finished, click the Create Request button.

**Add Documentation** action for [Emergency Releases]{.underline}. All
dispatch personnel associated with the transmittal and the verification
that an emergency message was placed and received by the intended
recipient will be documented. Use clear, simple text and avoid acronyms
and abbreviations. Discretion should be applied.

-   Do not document any information that is confidential and/or
    personal.

-   Limit documentation to pertinent information concerning the
    emergency release, identify all contacts for demobilization from
    departure point to arrival point.

-   Document that verification of information was passed and received by
    affected parties.

# Resource Status Screen

> All resources should reflect current status by using the appropriate
> level (Local, GACC, or National) within ROSS.
>
> **Local Resources.** These may be set as available for a GACC or a
> National dispatch after consideration of draw-down levels or part of a
> ready reserve operation.
>
> **National Resources.** The following resources should reflect status
> as available "nationally" unless assigned to an incident:

-   [Type 1 and 2 air tankers working under federal
    contracts,]{.underline}

-   [Type 1 Interagency Hotshot Crews (IHC),]{.underline}

-   [Type 1 and Type 2 helicopters working under federal contracts
    (Exlusive Use or Call-When-Needed),]{.underline}

-   [Mobile catering, shower, and commissary units working under federal
    contracts established by the national office,]{.underline}

-   [NIRSC radio items.]{.underline}

> **Resources assigned to "Preposition/Preparedness" incidents.** The
> availability status should be set to "Local." If not set to local, the
> resources home dispatch and home GACC will still view the resource as
> "Available."

**Self-status capability**[.]{.underline} Each resource will maintain
accurate status year round.

**Returning from assignment**[.]{.underline} The resource must have
status correctly identified as soon as possible. It is preferred that
re-status be accomplished within 48 hours. The length of assignment and
agency policy on mandatory days off will apply.

# Resource Item Screen

**Data Entry Standards**

For information on data entry standards, refer to the document entitled,
"Data Entry Standard for Resource Items in ROSS" at the location
identified below.

[ROSS](http://ross.nwcg.gov/documents_library/project_mgt/implementation_phase/Resource_Naming_Standards_2006_0317.pdf)
Resource Data Entry Standards

To prevent the duplication of crew resource records, units with hand
crews will maintain a maximum of one (1) crew record for each crew.
Dispatching units [will not]{.underline} create a new crew record for
each assignment, mobilization, or crew dispatch.

**Organizations**

Standards for this screen are being developed.

# Roster Screen

Certain agency resources will be configured using a roster as identified
below. Foreign government resources mobilized through NICC [are
not]{.underline} agency and [will not]{.underline} be configured using a
roster when assigned.

**Incident Management Teams**

-   Type 1 and Type 2 Interagency Incident Management Teams

-   National Area Command Teams

-   Interagency Fire Use Management Teams (FUMT)

-   National Park Service All-Hazard Incident Management Team

**Incident Support Teams**

-   National Interagency Buying Teams

-   Administrative Payment Teams (APT)

-   Burned Area Emergency Response Teams (BAER)

-   NPS Critical Incident Stress Debriefing Teams

-   National Fire Prevention and Education Teams

**Crews**

-   Agency Type 1 Crews (includes hotshot crews)

-   Agency Type 2 or Type 2 IA Crews (if comprised of regular agency
    employees)

**Equipment**

-   ICS Starter System, 4390

-   Kit, MAFFs Base Station, MBSK

-   Agency engines

-   Agency tenders

-   Agency dozers

> \- Agency tractor plows

**Aircraft**

-   Aerial Supervision Modules (ASM1 platform)

-   Lead Planes

-   Agency exclusive use helicopters and the permanently assigned module
    members

-   Agency owned helicopters and the permanently assigned module
    members.

# Tactical Aviation Screen

Standards for this screen are to be developed after October, 2007.

# Travel Screen

Use the **Create/Edit Travel Itinerary** to complete all mobilization
and demobilization travel for all resources assigned to off-unit
incidents. A Travel Itinerary is to be completed whenever there are
multiple legs (segments) to the travel. For example, several airline
connections or combinations of supply delivery that includes both air &
ground portions of transportation.

Always utilize the appropriate time zone for departure and arrival
locations.

\- Resources must have travel information entered into ROSS prior to
departure.

\- All segments of travel will be included as the travel itinerary.
Indicate if the travel includes a required layover.

\- Any deviation to the travel itinerary requires placing a telephone
call to the receiving unit. User entered documentation is mandatory.

> **Fill request.** Set ETD/ETA travel when filling the request.

-   [Mode of Travel]{.underline}. *Fill Request dialog box*. Identify
    the commercial airline, POV, and other travel details. *This field
    should be identical to the Mode of Travel field on the Travel
    screen.*