Why isn't there a default query record function like this following one in Appian which I made by myself

Question

Description: 
 
 rule!OE_QueryOneRecordTypeByForeignKey (recordType, fkField, value)

Gets a record based on its foreign key field value

recordType (RecordType): queried record type

fkField (Record Field): foreign key field

value (Number (Integer)): integer value searched

a!localVariables(
 local!queryData: a!queryRecordType(
 recordType: ri!recordType,
 filters: {
 a!queryFilter(
 field: ri!fkField,
 operator: "=",
 value: ri!value,
 
 ),
 
 },
 pagingInfo: a!pagingInfo(startIndex: 1, batchSize: 1)
 ).data,
 if(
 a!isNotNullOrEmpty(local!queryData),
 local!queryData[1],
 null
 )
) 
 
 if it was OE_QueryRecordTypeByForeignKey , then you simply remove the [1] indexing

Mathieu Drouin · Answer

Closest thing is queryRecordByIdentifier 
 docs.appian.com/.../fnc_system_a_queryrecordbyidentifier.html

Mike Schmitt · Answer

Unknown said: How would you make this refresh-always behavior? Could you please provide me some example? 
 Variables declared in a!localVariables() with default settings (i.e. without using "a!refreshVariables()" to set non-default behaviors) will default to "refresh on referenced variable change" of TRUE and other refresh styles set to FALSE. When local variables are used inside an expression rule like this, then that rule is used on an interface, it can lead to some tricky and unintuitive weird behaviors when in some instances, one would expect the value to update, but it doesn't. In this case if a new primary key is passed in, it WOULD update the result, but in some other corner cases it might not.

Mike Schmitt · Answer

This can be simplified a lot... 
 if(
 a!isNotNullOrEmpty(local!queryData),
 local!queryData[1],
 null
) 
 can be re-written as just, index(local!queryData, 1, null()) . 
 Additionally: creating a default record (and/or data store) query expression rule is up to the designer - I always do it for every new type I create. The huge benefit to doing it yourself is you get to develop then follow your own coding convention(s), and build in whatever shortcut(s) you personally like. 
 For instance, for every "default record/datastore query" expression rule I create, I not only have a rule input to quickly query the Primary Key ID, but i also create other optional rule inputs to query other commonly-used fields if/when necessary. The great thing about expression rules used in this manner is that they can be made to ignore any rule inputs not provided, so you can include a whole host of options that nest together if/when needed.