Timeout Default

The "Timeout" field is located on the request creation/dispatch page and allows the Manager to specify how long a Servicer has to "Accept" a request.  

If the Servicer fails to "Accept", the system will withdraw the request, sending the Manager a notification email and moving the request from "Requests in Progress" back to the "New Requests" table.  In the "Next Action" column, there will be a "Prior svc. req. expired " status message, and the Manager will have the ability to re-dispatch to the same or different Servicer (or to cancel the request by tapping the request number and tapping Cancel).

The default value is 720 hours (about 30 days).  Managers may edit the "Timeout" on a case-by-case basis or permanently, as follows:

1. From the Dashboard, tap Your Profile, on the left-menu bar.
   
2. Tap Set default environment variable values.
   
3. Edit the "Timeout" field (default must be in hours).
   
4. Tap the update button.

Tip 1:  These changes affect only the particular Manager account updated, so Managers may have different settings.

Tip 2:  Make sure to take things like weekends, special shifts, etc. into consideration.

Tip 3:  Default updates will only be applied to requests that have never been dispatched.  If a request was previously dispatched and then expired, and you are dispatching it again, whatever timeout was entered originally will still be in place.

• Related Articles

• FAQ: Why doesn't the Servicer's name appear after I've dispatched a request to them?

  Until the Servicer accepts the request, confirming that they are taking the job, dashes ("---") will appear in the "Servicer" column: After the Servicer accepts the request, or the Manager accepts it on their behalf, the Servicer's name will appear: ...

• Expired Requests

  When a Manager assigns a request to a Servicer (Vendor, Tech, etc.), there is a modifiable "Timeout" field on the dispatch page.  Unless changed, the system default is 720 hours (30 days); tap here for more information. If the Servicer (or a Manager ...

• CREATE REQUEST (Create For Requestor)

  Typically, you want Requestors to create requests themselves. However, in the event that you need to do it for them (or you want to get them in the loop on a project that will affect their location), this functionality will cause the request to ...

• FAQ: Can a Requestor with a top level home location (e.g. building or campus) create requests on the sub-locations (e.g. suites or common areas)?

  Yes, by default Requestors are able to create requests on sub-locations within a particular location, unless the Manager sets those sub-locations as invisible to the Requestor.

• Generate Requestor List

  Note: Requires admin privileges to implement. Please contact your Landport Administrator.  If you ARE your organization's Landport administrator and want to request Reporting privileges for yourself or a co-worker, please submit a Support ticket. To ...