REST Objects WorkItem

5.0.0

The WorkItem object is part of the overall ServiceBroker Configuration object, in the following location:

Configuration > Modules > WorkItem

A WorkItem object is used within the context of a REST Objects Modules (itself part of an REST Objects Configuration) to represent how the ServiceBroker's WorkItem module is configured - which controls a number of Work Item related activities - for the relevant tenant.

Do not confuse the WorkItem object (for representing how the ServiceBroker WorkItem module is configured for the relevant tenant) with the Work Item object, which represents the details of a Work Item.

On this page:

Related pages:

WorkItem Object Format

JSON Format

{
	"SrcSystem": "",
	"AltSrcSystem": "",
	"UseLocalStore": false,
	"UseMobileTechInfo": false,
	"DispatchingSystem": ""
}

WorkItem Object Properties

Property	Type	Required?	Description
`SrcSystem`	`string`	Yes	Defines the primary sub-system to use when a ServiceBroker GET Work Item API is called to get a Work Item record for the tenant. Although ServiceBroker supports searching multiple systems for appointments and then booking them, the WorkItem module does not yet support intelligently going to the correct primary-system where the Work Item was been booked when a follow up call to GET a Work Item booked through ServiceBroker is made. Instead, ServiceBroker will initially perform the GET request in the defined primary sub-system. This is a feature gap that is expected to be closed in a future release. Supported values: `SS`: The relevant tenant should use ServiceScheduling as the primary sub-system when performing a GET for a Work Item previously booked through ServiceBroker. Requires that a Scheduler provider object has been set for the tenant with a valid, enabled ServiceScheduling integration. `SD`: The relevant tenant should use ServiceDispatch as the primary sub-system when performing a GET for a Work Item previously booked through ServiceBroker. Requires that a OPS provider object has been set for the tenant with a valid, enabled ServiceDispatch integration. `SM`: The relevant tenant should use ServiceMobility as the primary sub-system when performing a GET for a Work Item previously booked through ServiceBroker. Requires that a Scheduler provider object has been set for the tenant with a valid, enabled ServiceMobility integration.
`AltSrcSystem`	`string`	No	Defines the *alternate* primary sub-system to use when ServiceBroker GET Work Item API is called to GET a Work Item record for the tenant. Although ServiceBroker supports searching multiple systems for appointments and then booking them, the WorkItem module does not yet support intelligently going to the correct primary-system where the Work Item was been booked when a follow up call to GET a Work Item booked through ServiceBroker is made. Instead, ServiceBroker will initially perform the GET request in the defined primary sub-system, as defined by the `SrcSystem` parameter above. However, if this GET fails to locate the requested Work Item, then ServiceBroker will repeat the GET request in the defined alternate primary sub-system. This is a feature gap that is expected to be closed in a future release. Supported values are as per the `SrcSystem` parameter above.
`UseLocalStore`	`boolean`	Yes	When `true`, Work Item objects that are created via ServiceBroker's REST Work Item APIs are stored locally. (See the Configuration > Transactions object for details on configuring how long Work Items should be stored for.) When a ServiceBroker tenant is configured with multiple sub-systems, this value must be changed from the default value of `false`, to `true`. Storing Work Item objects locally will ensure that when a Work Item is created via ServiceBroker, all of the fields required for the configured sub-systems will always be available to be passed to the relevant sub-system, when required. As an example, if `UseLocalStore` was not set to true for a tenant, and the primary sub-system for the tenant was ServiceScheduling, then an update to a Work Item in ServiceScheduling would mean that any fields that are not be stored in ServiceScheduling would not be present in ServiceBroker, and so updates made to the other sub-systems (e.g. ServiceMobility, ServiceDispatch) may lack important fields, and cause issues these non-primary sub-systems. Reminder: This setting applies to Work Item objects created via the REST Work Item APIs. For the same setting, but for Work Item objects create via the REST Work Item Appointment Book, see the REST Objects ApptBook.
`UseMobileTechInfo`	`boolean`	Yes	ServiceScheduling does not provide certain Worker information (such as the Worker's name). When `UseMobileTechInfo` is set to `true` for the tenant, then a ServiceBroker GET Work Item API call to get a Work Item record for the tenant, where that call is passed through to either ServiceScheduling or ServiceDispatch as the primary (or alternate primary) sub-system, will result in an additional API call to ServiceMobility to obtain this additional information, which will be merged into the results of the ServiceBroker GET Work Item API call.
`DispatchingSystem`	`string`	Yes	TBC

ServiceBroker 5

REST Objects WorkItem

Analytics

WorkItem Object Format

WorkItem Object Properties

Related content