Opinions needed: to include user-findable Last Modified and Record Created fields

[Rich S]

Greets, all:

I'm waffling between including Record Created and Record Last Modified fields in all of the layouts of a solution I'm about to market. I'm short on real estate and it'd be aesthetically more pleasing not to have those fields on-screen. For my own solutions I have them visible but for end-users, who 99% of the time probably don't care when a record was created or modified, does he or she really need to see these dates?

As an aside, the solution doesn't involve inventory or time-critical data so there's no got-to-know-when need for the dates.

TIA for your input,

Rich

[comment]

for end-users, who 99% of the time probably don't care when a record was created or modified, does he or she really need to see these dates?

Only you can answer this (and I believe you just did).

[LaRetta]

I might add that, if your Users ever need ability to search these Create and Modify fields (post subject says 'user-findable') then you can place them on a dedicated find layout which really should be used for finds anyway instead of your entry layout. Also, you can place 'less used' fields on tab controls.

[Rich S]

Just curious, LaRetta: Why have a separate/dedicated layout for finds? Wouldn't that be distracting? Say I have a layout full of demographic information and I want to find, say, all the people living in Austin--wouldn't I want to perform a Find in that same layout instead of being shuttled to/from a different layout?

[LaRetta]

Hi Rich,

Problem: If Users are left on regular layouts, they will become complacent and will not notice if they are in find or browse. Consequently, they can change real data thinking they are entering find criteria.

Answer: You can use conditional formatting and colorize the layout or fields when in find mode so Users can see the difference.

Problem: Users will be very displeased when they search an aggregate and their system hangs for 10 minutes; and not only their system but other Users will also feel the hit.

Answer: You can turn off entry to individual fields in Find Mode.

Problem: It never fails that the field the User wants to search is not on the layout. It may be an address field from the Customer (which is related). It may be a phone number of a contact (related to the customer). It simply never fails and you will eventually give up and create a dedicated layout where fields can be added easily to please your Users.

Answer: Tell Users they can't search for the contact's phone number from that layout because there isn't enough room. err.

Problem: Data-entry layouts frequently have script and/or layout triggers which have to be considered in the mix.

Answer: None

There are more but it is early ... hopefully others will chip in. I provided answers for each problem as well because nothing is set in stone in this business. But the answers involve additional 'field work' to add protections. I have started out so many times with just allowing finds on regular layouts and the next thing I know, I am adding a dedicated layout and it is more difficult after the solution has been running. It is more difficult on the Users as well, when you change a process midstream.

I build find layouts now right from the start and integrate it in during original navigation setup. It is simple to put a find button on every layout. Use script trigger on layout mode change when entering find to switch to list layout based upon that table. When find is performed, trigger returns them to form layout. It is easier for a User to enter their find criteria and still view multiple find requests on a list layout instead of viewing their find criteria scattered throughout a layout and even possibly hidden behind other tabs.

Find layouts have added benefit of more control and ability to assist your Users with messages, buttons and operators. Have you ever had a User scream in terror that all their records are gone - and they are switching from one layout to another and they all are gone? They never processed their find on that data-entry layout... They simply can not leave a find layout still in find mode.

I am pleased you asked the question, Rich. Many times we work through reasons we do things and then just begin doing them from habit. It is always good to continually review our decisions to be sure we are up on the best techniques available. So yes, if a User wants a simple city on a list layout of cities then it seems silly to switch them. But if sometimes you switched them and sometimes you did not, it would not be appreciated by your Users either.

Thank you for bringing it up!!