Discussion: What are your non-negotiable fields when publishing a form?

[EddyClark]

Mainly I'm trying to see if there are fields that could set me up for success in the future.  For example, I use the edit mode on forms a lot.  So I have a "last_edit_user" field that pulls from username.  That way if I edit the data I'll still know who it was before me.

Edit: I also just learned of the "mode" property that I could store in the data, so I know if the data is new or been edited.

[MobiusSnake]

Three fields I usually add to the top of my forms:

• A hidden "capture date" field that defaults to now().  Sometimes forms sit in outboxes for a while so I want to make sure I know when the field work was done, which edit tracking doesn't always accurately reflect.
• A hidden "username" field that uses pulldata() to get the username.  Sometimes a service's schema needs to be radically updated (e.g. adding related tables), and if data from an old version is migrated to the updated schema, edit tracking won't capture who originally did the work, it'll include the name of whoever did the migration.
• A note field with big red warning letters that's only visible if the user isn't logged in when they open the form.  This is to make sure the previous field gets captured.

[ClayDonaldsonSWCA]

I pull my companies internal project number system as an external csv. All my forms have project number as a dropdown as a required question, which allows me to use it for many projects. 

For photo repeats, I always include a geopoint - which makes it much more accessible to users in the front end.

I also include a note in the form itself that displays the version number so I can ensure people are up to date. This is necessary because many of my forms launch from field maps or QR code and it skips the details page.

[abureaux]

I have the following for all surveys with a geopoint. Non-geopoint sureveys are very similar, but just missing the few geopoint specific line items.

That IF() statement is quite long as it covers NL to BC (so basically NA): if(${header_utc_offset}='-2','-02:00',if(${header_utc_offset}='-2.5','-02:30',if(${header_utc_offset}='-3','-03:00',if(${header_utc_offset}='-3.5','-03:30',if(${header_utc_offset}='-4','-04:00',if(${header_utc_offset}='-5','-05:00',if(${header_utc_offset}='-6','-06:00',if(${header_utc_offset}='-7','-07:00',if(${header_utc_offset}='-8','-08:00',if(${header_utc_offset}='-9','-09:00',if(${header_utc_offset}='-10','-10:00','')))))))))))

All of these items get dumped into a tracking list to I can monitor items from a PBI dashboard. Some of these items are used in 98-100% of my automation processes (e.g., prime_pin_email is where I dump all emails for a form so I can send off various email notifications)

EDIT: These are set up as TEMPLATES, so all forms are these standardized items.

And since I talking about standardized items, I also have example groups and text items in my templates so that all forms have a similar look and feel. I don't want to re-invent the wheel each time. So, for the sake of this thread, I also have these:

(gn_pn is also a standardized field. The vast majority of my forms require a project number)