New VIEW==>ACTION Trigger: Record Viewed

[GreenFlux]

An action can be triggered when a form is submitted using the option:
UX>View>Behavior>Event Action

This feature request is for a new VIEW==>ACTION Trigger:

RECORD VIEWED

With the Form Saved trigger, the action runs AFTER the form is saved, allowing access to reference the values just entered.

The Record Viewed trigger would need to run IMMEDIATELY BEFORE the record loads. This would only work on Detail views, or maybe Dashboards.

---

Use Cases

• Auto-stamp values for [LastViewedBy] , [LastViewedAt]
• Auto-mark items as ‘Read’ when opening in full screen (Table view to Detail)
• Auto-run an action while cycling through records in slideshow. (left/right arrows in Detail View)
• Improve performance by replacing Virtual Columns with sheet columns for ‘expensive’ formulas that don’t need to be displayed in list view. (Would only update when viewed in detail view)
• Trigger an action when user opens a notification!

---

Thanks for considering!

[MultiTech]

But in order to get to a detail view… you must either:

• go through an inline view, or
• manually been directed there with a navigation action.

In either instance, we (developers) have a chance to get our hands in there and do what we want.

---

For instance: if I wanted to add a view counter to a record, and people were viewing the detail by tapping on a table record - I would insert the counter action into the table (deck/gallery/etc. any inline) view that the user is tapping on to get there. (Not on the detail view.)

[GreenFlux]

MultiTech_Visions:

But in order to get to a detail view… you must either:

• go through an inline view, or
• manually been directed there with a navigation action.

You have left out several cases which would not provide the developer an opportunity to insert an action on record load:

• Typing a valid URL directly in the address bar to a specific row
• Reloading a saved favorite to a URL for a specific record
• The Left/Right -SlideShow arrows in detail view

The method you are suggesting would require ensuring the trigger was attached to all possible ways to enter the detail view, and the above methods would still be missed.

---

The idea here is that the act of loading a specific view would trigger the action, regardless of how the view was loaded.

It would be tied to the destination view, not the origin, and be a true indication that the view was loaded, rather than an attempt to capture every possible ‘entry-path’ that the user could take to load the view.