When creating a record type, I need to create a Summary view (or any other view)

When creating a record type, I need to create a Summary view (or any other view). When defining the interface, I want to pass the entire object to the interface rule input. For instance, if I have a Person entity, I could access that person's name doing rf!name. Instead of passing all of the paramters one by one, could I pass the Person entity itself and use it on my interface?

OriginalPostID-183659

OriginalPostID-183659

  Discussion posts and replies are publicly visible

  • Pass in the object ID for e.g. rf!id and use a query entity OR query rule to fetch the entire object as required.
  • I thought about that but which is the best practice? In this case, which one has best performance? For example, I could simply pass all the values instead of querying the database with the rf!id. Is it better that way?
  • @erickp I believe that maintaining only those attributes that are needed in List View, Filters and fields required for Related Actions (as start parameters) are sufficient. Passing the entire object makes the maintenance complex as per my knowledge. As and when you need to add new attributes in any of the Record Views, you need to alter the source of record for same because the source of the record will always contain only those columns needed in List view or Record Views of Record. And next to this though you pass the entire entity to the Record View, you can't say that there isn't any need of queries. For instance, if you want to surface data related to an entity other than the Record's source, then again you should go with querying. So as per my knowledge, it would be good to pass rf!id and later on query the entity based on id. This keeps the implementation quiet simple and easier to maintain. And re best practices, you may achieve the same by keeping few things as follows in your mind:
    1. Make sure that the queries are made in load() (But also bear in mind that loading lots of data in load() leads to bad performance. So if the data is from multiple tables, try to construct a simple join if possible. And in some cases, we can intelligently design the interface so that the data will be queried 'on-demand' i.e. when user clicks some link or button namely 'View details' which gets further datasets. And also try to keep the queries minimal in count and amount)
    2. Make use of queryEntity() and retrieve only those fields that are needed.
    3. Further make sure that the database entity doesn't consume much time while retrieving data, for instance complex joins, bad native sql queries in views results in slow execution of views which thereby causes a delay in Appian's query rules as well.
    4. Query the records in batches when ever possible.
  • @sikhivahans I appreciate the answer. Very informative!
  • @sikhivahans passing just the id and later using queryentity makes sense for maintenance. But, my concern is about the additional DB call. So, with this approach when let's say cdt changed you only have to update the sail rule(s). With other approach of passing each parameter with rf! then and when cdt changes you have to update record and SAIL but, no additional db call each time the record is opened.

    Which approach is the best practice?