Like most organizations, most opportunities have just a single payment. We make use of information on both the opportunity and the payment, including key payment fields such as date paid (banked date or postmarked date if accrual time period boundary), payment method, check number or, equivalently, any note about how we are paid if not a check. It was pretty normal to need to edit one of these key fields and it requires clicking into the opportunity. I wanted to make the UX better.
The first level improvement was to add a single list of payments on the page layout visible with the opportunity details. If one has a priori information about needing to edit a payment, you can do so right form that single related list using the pull-down triangle. But you can’t see the details so you have to somehow know in advance. This is plausible for some tasks like clearing reports of records that need clean-up periodically.
We wanted to also make it easier for the user to see if information was faulty and edit it on the same page. This is a great use case of Lightning Pages designed to get the job done without leaving the page. We added a look-up field on the opportunity to the “last” payment.
Even though we plan on filing the value of this field automatically, it can be deleted or added from the UI. Therefore we setup filter for values as follows:
We add a “related item” component to directly show key information and edit it right in place. The component appears right next to the key opportunity fields.
The Related record is set up as follows and is only visible if the opportunity is closed/won.
It has an associated quick action that defined the field layout:
The new lookup field on the opportunity is populated when the first payment is created and reevaluated on each subsequent edit or create of a payment by a flow.This type of reference is called a “look-down” reference since it sits on the parent and looks down at the various child objects and points to one of them. Contrast that to a roll-up field that takes data from each of the child records and pushes a summary up to the parent. The flow is a record-triggered flow on create or update of a payment record. It has to be after-save because it needs access to the opportunity record. The logis is very simple as shown:
Like most fields calculated by automation that are added in midstream, the above flow assumes the database is already filled with correct values of last payment lookups. But our database was initially blank, of course. So we wrote a scheduled flow to do the record updates on a one-time schedule as follows. It could be used anytime if we modified how we compute or found the data to be somehow corrupted:
Because payment method is such a key field for us in terms of data integrity, we also added a formula field on the opportunity that uses the new lookup field and pulls the payment method of the latest opportunity. This allows us to filter on that payment type field being empty, for example, in a list view. It is also already heavily used in reports as of April 2021.
This relatively simple addition shows the power of the Lightning pages. UX design needs to continue to move away from presenting records serially (First go to this page and do xxx. Then go to the child record and do xxx. Then go to the parent account and do xxx.) Instead the user enjoys a good experience where they use the search bar to find the right record for doing this job and related objects or fields are presented from multiple objects so the job can be completed on the page when possible.