Feature Request: please enable local variables In records

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.

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

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

Actually you are right. With initial look at new version the expression rules were also listed as web service.

Even if this is possible we have limitations as I posted earlier

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.

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

The new nested data in records can fix most of the scenarios though.

Just curious - is your primary concern the performance of getting data from these other sources? What kind of performance are you seeing currently and how many views / queries are you currently doing?

Hi Peter,

Yes Performance is the main concern here. We have API's and query entities to fetch user access information which needs to queried in all 12 related actions. This is would be lot better to have a local variable section in record type which can be used all over the record.

We also have some API's to fetch data related to record item which should be used in view/related actions

This was one of the use case I observed, I have seen same thing in my previous projects as well.

I know this might be a large ask but just putting it out here so that it can be considered and I strongly believe I am not the only one who need this