+4Hi Jeferest,
get_case_context_property(property_key)
Get a case context property.
| Param name | Param type | Definition | Possible values | Comments |
|---|---|---|---|---|
| property_key | {string} | The requested key property | N/A | N/A |
+1Hi Ben, I'm aware of the get_case_context_property() function... But I need a way to retrieve the case context properties dynamically without knowing which properties are attached to a case beforehand (different playbooks can be run which add different properties). Is there a way to do this, either with a SDK function call or an API endpoint I can check?
+12I don't know of a way to do this. But there is a workaround, but it has a consideration.
Consider
Case.allMythings.key1
Case.allMythings.key2
allMythings is an intermediate JSON key, that stores your dynamic keys inside. This way you can have dynamic keys in a discoverable location.
The value of [Case.allMythings] will be stored/retrieved as a string, so any time you need to edit/update you will need to get the context value, buffer it into a JSON object, then modify and push back. This would scale well in a Block, but not if you are managing this in a Block (as the platform does not go 2 Block layers deep)
For anyone reading, 2 friendly reminders on context keys:
- Keys are indexed, if you creates lots of keys this will have a non-positive affect on the system. e.g. don't use UID/SHA256 as the keys, and then spam this method
- Values are not designed for big objects. Small strings, integers yes, but please dont; store files/objects in there, this is not the right place.
+5I don't know of a way to do this.Β But there is a workaround, but it has a consideration.
Consider
Case.allMythings.key1
Case.allMythings.key2
allMythings is an intermediate JSON key, that stores your dynamic keys inside. This way you can have dynamic keys in a discoverable location.
The value of [Case.allMythings] will be stored/retrieved as a string, so any time you need to edit/update you will need to get the context value, buffer it into a JSON object, then modify and push back.Β This would scale well in a Block, but not if you are managing this in a Block (as the platform does not go 2 Block layers deep)
For anyone reading, 2 friendly reminders on context keys:
- Keys are indexed, if you creates lots of keys this will have a non-positive affect on the system. e.g. don't use UID/SHA256 as the keys, and then spam this method
- Values are not designed for big objects.Β Small strings, integers yes, but please dont; store files/objects in there, this is not the right place.
β
is there a place or way to perform cleanup? I can see that we have some old not used context that are still showing under our case placeholder. I would like to get rid of them - is there any method for that?
+12AFAIK there is no delete, but you can set it to β-β
There is unlikely to be any problems with storage or speed, I assume this question is about keeing the Alert view cleaner?
+5AFAIK there is no delete, but you can set it to β-β
There is unlikely to be any problems with storage or speed, I assume this question is about keeing the Alert view cleaner?
it is not on cases but overall inΒ β [Β ]Β β you are able to see those wrongly created placeholders/context
so in case/alert there are no issue - only with predefined remembered by platform fields
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
