Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 5 Next »

5.0.0

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

An ApptBook object is used within the context of a REST Objects Modules (itself part of an REST Objects Configuration) to represent how ServiceBroker should handle the booking of appointments through the configured Providers, for the relevant tenant.

On this page:

Related pages:

ApptBook Object Format

JSON Format 
{
	"AllowRebook": true,
    "UseLocalStore": true,
	"EnableWIN": true,
	"UseSrcSysResult": false,
	"TransformIn": {}
}

ApptBook Object Properties

 

PropertyTypeRequired?Description
AllowRebookbooleanYes

When booking an appointment, should ServiceBroker send the AllowRebook flag to the Provider, where supported? (Both ServiceDispatch and ServiceScheduling support the AllowRebook flag.)

Setting this flag to true informs the Provider sub-system that, for the relevant tenant, if the booking is being made in that if a Job ID is provided as part of the booking request, and that ID is already present in the sub-system, then the existing booking should be updated with the new details - in essence, allowing an existing job to be re-booked to a new time.

When this flag is set to false, then re-booking will not be permitted for bookings made via ServiceBroker for the relevant tenant.

UseLocalStorebooleanYes

When true, Work Item objects that are created via ServiceBroker's REST Work Item Appointment Book 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 Appointment Book.

For the same setting, but for Work Item objects create via the REST Work Item APIs, see the REST Objects WorkItem.

  • No labels