Best Practice for Sharing Service-Specific Properties from Host to Central?

Liberty Create
1

When we create a new service, we create a rule that copies values from attributes and properties within the service’s process-oriented object into the corresponding fields in the Summary CASE object. Current Activity, State, and Case Ref properties, which already have matching properties in the Summary CASE object.

What I would like to do, if possible, is copy some service-specific properties into the Summary CASE object so that they can be displayed on a Case List page in Central. This page would only be visible to a specific user group, and for it to be useful, I’d like to include some properties that are unique to this service.

Because these properties are only relevant to this particular service, there are currently no corresponding fields in the Summary CASE object. I understand that the Summary CASE object is used to aggregate information from all cases across all services within the Host application, and that this information is then shared with Central. However, I’m not clear on how the data is transferred from the Summary CASE object in Host to what I assume is the CASE object in Central.

Could someone advise on the correct approach if I want to make properties from my Print Order [DATA] object in the Host, available in Central? Is it simply a case of:

  • Adding the required properties to the Summary CASE object in Host.

  • Populating those properties via a rule.

  • Making corresponding changes in Central

If so, what additional configuration is required in Central to make those properties available and usable on a Case List page?

New Liberty user, hope this question makes sense.

2

There is an API call called Create or Update Summary Case on the host that targets a corresponding function in central to create and update the Case Summary records, so at a minimum you would need to update the Case Summary object in central to have properties to record your service specific data, then update the function in central to accept data for these properties, then update the call on the host to send the properties. Should be relatively straightforward.

Of course if this is done repeatedly for different services across different hosts the central object could get unwieldy, with lots of properties that might not be relevant on any one host but have to be exposed to it. An alternative we have created is to have an object on central related many2one to the case summary object that can store “Key-Value” pairs, then created an api function on central that accepts 3 values: a case summary ID, a key, and a value. You can then call this from any host and provide the case summary ID from the main CASE record, and a key and value to store. You can use the key to find the value again for updating it and to filter the list in central. Essentially it allows you to have as much extra info in central as you like with only a single simple api function and call, and whatever rules are needed on the host to update the key-value pairs. Might be overkill for your purposes for now but perhaps something to consider in future.