Looking for best practices/methods for dealing with these two scenarios:
How do you hold onto deprecate fields that you still need around for reporting without cluttering-up custom forms? In other words, I understand I can't remove a deprecated field because it would vanish from older jobs and lose data.
What do you do with "utility" fields? For example, calculated value fields that are unimportant to the user, but I need there to create a value used on a report somewhere or to set a metadata flag.
I thought you could create a section and hide it to all but SysAdmins, but I discovered this hides the value of that field from user reports. :-( So right now I'm stuck with having a "Systems Administration" section at the bottom of every custom form that needs it, and it has to be visible...and I'm not liking that idea. It should be noted that our custom forms are not set-up in isolation: a given input brief (request/issue) is made of 4-5 custom form modules we can swap in and out and modify separately from one another, for example: A requester might fill out a series of custom forms in a single go:
Project Level Metadata [boilerplate to all input briefs]
Accounting Information [boilerplate to all input briefs]
Instructions [no fields, just general form instructions]
Request Brief [specific to the request chosen]
Extra Sub-Brief [boilerplate across multiple Briefs, but not on ALL of them]
This library lets us build whatever combos we need without re-inventing the wheel for big chunks of it. But it also means whatever solution proposed above will show-up multiple times from the user's perspective if it's per-form. :-( We're only a couple weeks into deployment, but these sorts of things are already important and I have a chance to set best practices now before things get crazy... Kevin Quosig