Skip to main content
andreac818829
andreac818829
September 22, 2025
Solved

Migrating Wrapper Rules to Appian 25.3 a!queryRecordType()

  • September 22, 2025
  • 7 replies
  • 0 views

Hi everyone,

With Appian 25.3, a new version of a!queryRecordType() was introduced, and the previous version is still available as a!queryRecordType_25r2(). This evolution brings more control and clarity over which fields are retrieved.

Key difference between the two versions

25.2 - a!queryRecordType_25r2()

  • When no fields are specified, all base record fields are returned automatically.
  • Even if only relationship fields were passed, the base record fields would still come back unless explicitly narrowed down.

25.3 - a!queryRecordType()

  • When no fields are specified, only the primary key (id) is returned.
  • To retrieve all fields, the new a!selectionFields() function should be used with its allFieldsFromRecordType parameter.

Why this matters for wrapper rules

In our applications, most queries are wrapped in a reusable rule that takes a single fields input. Callers of these wrappers don’t (and shouldn’t) need to worry about the function version or its internal implementation.

To align with the new function, the wrapper needs to:

  1. Identify base record fields in the fields input. If none are present, automatically include the base record in allFieldsFromRecordType.
  2. Identify relationships in the fields input. These should also be passed into allFieldsFromRecordType.
  3. Always pass the requested fields to the selectFields parameter.

This way:

  • If callers specify base fields, only those fields are retrieved.
  • If callers specify no base fields, all base fields are retrieved by default.
  • Relationships continue to work as expected.

Expressions we are testing

Detecting base record fields

  • ri!record: an empty instance of the base record containing no fields
  • ri!fields: the same list of fields passed to the wrapper rule

if(
  and(
    a!isNotNullOrEmpty(ri!fields),
    a!isNotNullOrEmpty(ri!record)
  ),
  rule!LGTCP_RejectNulls(
    input: a!forEach(
      items: a!keys(
        a!update(
          ri!record,
          ri!fields,
          a!forEach(ri!fields, null)
        )
      ),
      expression: if(
        typeof(fv!item) = 284, /* Record field */
        fv!item,
        null
      )
    )
  ),
  null
)

Detecting relationships

  • ri!input: the same list of fields passed to the wrapper rule

cast(
  /*Record Relationship*/
  a!listType(298),
  if(
    a!isNotNullOrEmpty(ri!input),
    rule!LGTCP_RejectNulls(
      input: a!forEach(
        items: ri!input,
        expression: if(typeof(fv!item) = 298, fv!item, null)
      )
    ),
    {}
  )
)

Implementation

a!queryRecordType(
  recordType: ,
  fields: a!selectionFields(
    allFieldsFromRecordType: {
      if(
        a!isNullOrEmpty(
          rule!ExtractBaseRecordFields(
            record: (),
            fields: ri!fields
          )
        ),
        ,
        {}
      ),
      rule!ExtractRecordRelationships(input: ri!fields)
    },
    selectFields: ri!fields,
    includeRealTimeCustomFields: true
  ),

Open questions for the community

  • Has anyone else approached this migration in a different way?
  • Do you see a simpler or more robust method to distinguish base fields vs relationships in the fields parameter?
  • Any best practices for structuring wrapper rules around the new a!queryRecordType()?

Best answer by peter.lewis

Yeah I agree with Aaron but to add even more context - I expect the new behavior of explicitly selecting the fields you need to be the main approach going forward for a!queryRecordType(). While it may be beneficial temporarily (for backwards compatibility reasons) to make your wrapper rules to behave like the old version, I think this is a good point to start creating new wrapper rules that incorporate the new behavior and "deprecating" the old ones (maybe by renaming like [mention:8e5a7a058e4f4768ba94c8d9526dd3e4:e9ed411860ed4f2ba0265705b8793d05] suggested).

7 replies

stefanhelzle0001
stefanhelzle0001
September 23, 2025

We follow a different approach.

We have very clear patterns to query individual record items or lists of items of a specific record. To avoid any problems in the long run, we always return all fields including extra long text and custom record fields. And, we create separate expressions for each type of record and or query. The hugely improved readability of the code easily pays of the added effort.

And then, we have other queries, which are typically not reused and very specific to a use case. We typically do not create separate expressions for such cases.

We do not use any kind of wrapper expressions for queryRecordType.

    harshk1671
    harshk1671
    September 23, 2025
    We are aligned on the approach, thanks for bringing this into the discussion. I propose renaming the current rule to _25r2 and leaving its implementation untouched, as it's already in use across multiple applications. Instead, I’ll create a new rule for future use. This will allow us to:

    • Avoid regression testing on the existing implementation

    • Eliminate the need for custom logic to support both old and new versions

    • Fully leverage the capabilities of the new implementation

    I’d still appreciate hearing everyone’s thoughts on this.

      andreac818829
      andreac818829Author
      September 23, 2025

      Hi [mention:a11f77a729fb4db2af76b09948583328:e9ed411860ed4f2ba0265705b8793d05] , thanks for your reply.

      Just to clarify and avoid any confusion: our “wrapper rule” approach is also one rule per record type, similar to your pattern of having clear, dedicated expressions per record.

      Where our use case differs a bit is that we were relying on these rules not only to fetch all fields, but also for cases where we wanted to retrieve specific subsets of fields (e.g. only a few base fields, or a mix of base and relationship fields).

      Now, with the new a!queryRecordType(), our wrapper needs a reliable way to detect whether the fields input contains any base-record fields (as opposed to only relationships or relationship fields). If there are base-record fields present, we should pass those as the selection; if there are none, we want the wrapper to automatically include the base record in allFieldsFromRecordType (and include any relationships) so callers that expect the “all base fields when none specified” behavior don’t need to change.

      We also understand that we could simply preserve the old versioned function, like [mention:8e5a7a058e4f4768ba94c8d9526dd3e4:e9ed411860ed4f2ba0265705b8793d05] suggested, and introduce the new one with a slightly different contract (for example, separate parameters for fields vs all-record fields). However, staying aligned with Appian’s latest version of such an important function is valuable for us. At the same time, we’d like to avoid always querying every field by default, since for the same reasons Appian introduced this new standard, it’s not best practice to always select everything.

      Our proposed solution works as intended, but we were just wondering if there is an official or better approach to achieve the same behavior.

      F
      fredericon
      September 23, 2025

      [mention:6b9f80ff18f9420082d13ef2d5121d56:e9ed411860ed4f2ba0265705b8793d05] hope you are doing fine. It would be possible to get also your insights about this discussion? Thank you

      aaron.rapp
      aaron.rapp
      September 23, 2025

      I'll leave the first two open questions from the OP to the community to answer. However, in terms of best practices, Andrea correctly identified the intent of the function changes and that the recommendation is to always only select the fields you need, which also extends to any wrapper functions you build.

      J
      jessek855119
      September 23, 2025

      Be extremely cautious with includeRealTimeCustomFields  defaulted to true in generic query rules. Without an existing rigorous performance testing regimen, it will not be obvious that the custom record field is the root cause of performance issues since it will appear that "every" query to the record type (via the generic rule) is performing poorly. It's the equivalent of doing SELECT * in a complex SQL query / view, but without the benefits of an explain plan.

      If the rule is purpose-built, then this is less of a concern since the use cases are more specific . However, in generic rules that are used everywhere, later introductions of real-time record field(s) to the record type will likely cause unexplained performance issues in the data fabric across every part of your application that uses the generic query rule - even for a dataset of only 100k rows, and even after Data Fabric 2.0 (25.1). Don't ask me how I know [emoticon:4b473fb4671244b2a5887318abe9e44a].

        Terms & ConditionsAccessibility statement