Skip to main content
Known Participant
May 24, 2021
Question

Feature Request: please enable local variables In records

  • May 24, 2021
  • 9 replies
  • 1 view

Feature Request:

Enable local variables where we can query or get some important data related to a record item so that it can be reused in all the of the related actions visibility because we usually do same set of queries/group checks most of the time. 

9 replies

mikes0011
Brainy
May 24, 2021

I know what you mean, but I hope you realize how major of a change this would be - AFAIK it would require the entire construction of the record type to be fundamentally altered.

As a workaround, I've actually seen this done inherently in the "record view source expression", where the work is done in a custom / external expression rule, where various visibility aspects are evaluated all at once (such as various "group membership check" functions etc), then passed back via the manual construction of a specialty CDT that's the same CDT used for the record's Data Type.  This can at least work for view and related action parameters and visibility settings, saving you from having to run duplicative logic many times for each entry.

The Expression Guru
Known Participant
May 24, 2021

Hi Mike,

Thanks for the alternative but in newer version of appian I don't think creating a record based on expression rule is possible. Now if we try to create service backed record it has to be on integration. Also if there is a way for it we will be loosing lot of interesting feature such as immediate record sync, export to excel.

Adding this local variable would improve ton of performance for most of the records

stefanhelzle0001
Brainy
May 24, 2021

A service backed record just takes an expression which has to create a data subset. It does not matter where this is coming from.

stewart.burchell
May 24, 2021

Data related to the core record can be brought into context in one of 3 ways:

  1. as mentioned by the other responses, you can use an Expression-back record at assemble the related data in the expression itself. This will work but will have a performance overhead as you're making two or more round-trips to the data source
  2. you can make a 'VIEW' in the database, effectively bringing the data together in one place. Your record then is still entity-backed but is now referencing the VIEW rather than the original entity
  3. Modern records all you to nest related data in the underling CDT which conceptually works much in the same way as a VIEW does.
Known Participant
May 24, 2021

Hi Stewart,

My request was not something to do with passing record source into sub rules/interfaces. For example we have user access related information in database which will allow/deny/readOnly access to certain related actions in those cases we would have to run the same query in all the related action context which uses it. We cannot use views here due to one to many relationship between tables. Also this is just one of the use case