REST Objects ApptSearch

An array of strings, defining which configured Providers should be used when searching for appointment offerings when not directed to specific Providers via a matching SearchRules value, for the relevant tenant.

See the description above which explains when and how the Providers value is used.

Supported values:

• SD: When set, a search for appointments can be performed in an integrated ServiceDispatch sub-system, when required. If the SD value is set here, this requires that an OPS provider object has been set for the tenant with a valid, enabled ServiceDispatch integration.
• SS: When set, a search for appointments can be performed in an integrated ServiceScheduling sub-system, when required. If the SS value is set here, this requires that a Scheduler provider object has been set for the tenant with a valid, enabled ServiceScheduling integration.

A string, defining which of the configured Providers values should be used as the preferred Provider, for the relevant tenant.

See the description above which explains when and how the PreferredProvider value is used.

When null, no preferred Provider is configured for the tenant.

Supported values:

• SD: When set, ServiceDispatch will be used as the preferred Provider. If set, this requires that SD be present in the Providers array, and that an OPS provider object has been set for the tenant with a valid, enabled ServiceDispatch integration.
• SS: When set, ServiceScheduling will be used as the preferred Provider, If set, this requires that SS be present in the Providers array, and that a Scheduler provider object has been set for the tenant with a valid, enabled ServiceScheduling integration.

An array of SearchRules, which are evaluated in order.

If no SearchRules are required, the SearchRules object may be omitted.

See below for a SearchRules example.

One of three defined string values, which determines how the rule should be evaluated.

Supported values:

• Any: When the Type is Any, then if any one of the matches in the Matches array matches, then the rule matches (i.e. logical OR evaluation).
• All: When the Type is All, then all of the matches in the Matches array need to match, for the rule to match (i.e. logical AND evaluation).
• DataSet: When the Type is DataSet, then if the match in the Params object matches, then the rule matches.

An array of one or more matches to be used when evaluating the rule, when the Type of the rule is either Any or All.

Required when the Type of the rule is either Any or All.

Each match is a JsonPath filter, which is evaluated against the search object supplied via the REST Work Item Appointment Search.

An object defining the match to be used when evaluating the rule, when the Type of the rule is either DataSet.

Required when the Type of the rule is DataSet.

The Id of a data set, defined via the Data Set API, which must already exist in ServiceBroker for the relevant tenant.

A string defining the relationship between the Value and the data set.

• In: The rule will match when the Value is in the data set.
• Out: The rule will match when the Value is not in the data set.

The field of the search object supplied via the REST Work Item Appointment Search which should be compared with the data set.

An array defining the Providers that the appointment search should be sent to when the overall rule matches. The array must contain one or more strings, defining which Provider or Providers to send the appointment search to.

Supported values:

• SD: When set, the appointment search will be sent to ServiceDispatch. If set, this requires that an OPS provider object has been set for the tenant with a valid, enabled ServiceDispatch integration.
• SS: When set, the appointment search will be sent to ServiceScheduling. If set, this requires that a Scheduler provider object has been set for the tenant with a valid, enabled ServiceScheduling integration.

An object, containing both an SD and a SS sub-object.

The SD sub-object defines any default search object values which should be added to the search object supplied via the REST Work Item Appointment Search call, at the point immediately before the search is made to the ServiceDispatch sub-system, for the relevant tenant.

The SS sub-object defines any default search object values which should be added to the search object supplied via the REST Work Item Appointment Search call, at the point immediately before the search is made to the ServiceScheduling sub-system, for the relevant tenant.

• If the search object supplied via the REST Work Item Appointment Search already contains a value defined in the TransformIn object, then the value from the API call will be used. Property values defined in the TransformIn object are only added when the property does not already exist.
• Property values are added to the search object only immediately before the object is sent to the relevant sub-system. As a result, property values from the TransformIn object cannot be used in the evaluation of SearchRules.

Where no default search object values should be added to the search object, the relevant sub-object should be an empty object - for example:

"TransformIn": {
	"SD": {},
	"SS": {}
}

As an example where default search object values are to be set:

"TransformIn": {
	"SD": {
		"WorkType": {
			"Name": "WORK_TYPE"
		},
		"Location": {
			"Postcode": "12345",
			"Country": "USA"
		},
		"Product": {
			"BrandCode": "CODE_1",
			"ProductCode": "PROD_1"
		}
	},
	"SS": {
		"WorkType": {
			"Name": "WORK_TYPE"
		}
	}
}

With the above TransformIn value set in a tenant's AppSearch object:

• Any searches for appointment offerings sent from ServiceBroker to the configured ServiceDispatch sub-system for the tenant would have the following search object property/values added, whenever there was not an already existing property value set:
  • WorkType > Name: WORK_TYPE
  • Location > Postcode: 12345
  • Location > Country: USA
  • Product > BrandCode: CODE_1
  • Product > ProductCode: PROD_1
• Any searches for appointment offerings sent from ServiceBroker to the configured ServiceScheduling sub-system for the tenant would have the following search object property/values added, whenever there was not an already existing property value set:
  • WorkType > Name: WORK_TYPE