Chris, thanks for chiming in.
Though I like the concept of field level security, my experience tells me that this approach may do more harm than good. I have found that there can be unintended consequences with field level security. Here is an example:
After upgrading to 10.1 we made the Labor Rate value on the Employee, Labor Detail and Job Operation records visible only to certain security groups so that floor personnel could not see the labor rate of other workers. What we found its that doing so caused the Burden Rate to set to 0 on labor transaction for any user with the restriction. It appears that the business object has the same restriction as the user. In this case, the labor rate reads as 0 to the user and to the business object, which multiplies it by the burden percentage and gets 0 in return. I certainly did not expect this result, but I suppose it makes sense. I did report it to Epicor Support–I believe they indicated it is working as designed.
In this case, I would be adding the field level security to many fields on several tables. What happens, for instance, if a checkbox field that the business object sets to true on record creation finds that it is read only? Ugh!
Also, using field level security would make the fields read only across the entire application. Though that may be OK, I imagine there may be exceptions.
I think this leaves me where I started–row rules that reference user security groups.
Michael