Best practices for UD fields?

Adding in some UD fields to help track some company unique information. I haven’t ever done it before but believe that I understand the premise of it.

So…Are there any best practices for creating UD fields? Things I should do or not do to make my life easier?

The only “best practice” for UD fields would be mostly common sense. Make the field name something descriptive… something like “AQLRequired_c” for a field on the Part table for a part where whatever “AQL” means is required for that part. Then in the Description field, say what it’s for, why it was created, and any other information (like associated screen customizations or BPMs) that somebody ELSE might be able to use someday to figure out what the heck it is.

1 Like

Are you implying risk job security for proper documentation?!? :upside_down_face:

That all makes sense though. Thank you.

Remember… “if you can’t be replaced you can’t be promoted”.

Someday maybe you will get promoted.

1 Like

Hey… that is MY line… hahaha… a boss told me that back in 1985… best words of wisdom that I ever received!

It’s honestly great advice.

Make sure you define the length properly. It’s easy to overlook and leave the default for String at 8 characters. I also make sure to put in a description to explain what it’s purpose in life is. Yes you may have documentation somewhere but that’s really handy and easy to use without having to go somewhere else to get the story.