[ Experts Corner Request ] Field Security vs Extended Properties

Anyone with better understanding - up for creating a Experts Corner Article sharing the differences (pros/cons) of Field Security vs Extended Properties

Such as:

  • How are DMTs Affected
  • How are Method / Data Directives Affected
  • How are Updatable Dashboards Affected
  • How are Adapter Methods Affected by Field Security (I see often users just go to Field Security, not knowing that Extended Props has that magical hidden “view”)
  • How does Epicor’s Field Security Engine work (does it censor columns, exclude them or not even transfer them over net.tcp if None is Set?)
  • Extended Props has DataTables, Field Security Doesn’t
  • Is it okay to apply Read Security to PartTran.TranDate (seems kinda broad)
  • If you apply Field Security can it still be set by Print User or Async / Sync BPM?
  • Best Case for Extended Props
  • Best Case for Field Security

@aidacra @Bart_Elia @erikj @josecgomez @Rich @Chris_Conn @Mark_Wonsil @markdamen @edge @timshuwy


Field Security vs. Extended Properties vs. BPM. We do use security group membership to control access to certain fields. It’s nice because it doesn’t bypass Security Manager - unless you want it to…

Mark W.

1 Like

Also how these should be used in a multi company environment.

  • Do you set either in one company or do you need to set up for each company?
  • Can we set different security or different properties for each company or do they have to be the same for all companies?


1 Like

@timshuwy where are you!!! :slight_smile:


We only have one and it appears that it can be set company-wide as well as a single company. All of our security groups begin with the company ID or with a global identifier so we can control cross-company access.

Mark W.

@Mark_Wonsil you are correct. What I am looking for is more best practices and documentation on how Epicor suggests we use this in a multi company environment.

Personally, I like BPM security for WRITE access to fields (ie… when you want someone to SEE a value but not CHANGE a field… reason, is because you can “logic based” rather than an all or nothing approach.
Example: Sales user is allowed to DECREASE the credit limit, and they are allowed to put a customer on-credit hold, BUT they are not allowed to INCREASE the credit limit or take the customer off hold. This logic based can easily be done in a BPM either in a Data In-Trans BPM or in a method BPM depending on the need.

Thy request is my command for I am this site’s humble(ish) servant.

And in 10.2.300, there is an additional X factor to throw in that piggybacks on the field security framework called data masking which I’ll throw in free of charge.

Give me a little bit to put it all together.

EDIT: spoiler, I am biased against field security but I’ll try to be as neutral as I can.


AWESOME!!! I’ll make sure @josecgomez and @Chris_Conn get you drunk during Insights 2019. :slight_smile: i’ll throw in @Drozy2017 to buy dinner :slight_smile:

Haha i barely got to go to Insights 2018 - and only because it was down the road from my house :stuck_out_tongue: I dont think they’re sending me to Vegas :frowning:

Think about all those slots I am gonna miss out on… time slots for courses of course.


@Bart_Elia packs light, he always has extra room in his suitcase.

Just an update. I haven’t forgotten, just waiting until after October 1, 2018 so I can claim this white paper towards my FY2019’s annual review accomplishments :face_with_monocle:



1 Like

Make the stats @aidacra :slight_smile:

I have yet to get field security right. Either is half works or the step you have to go through to set it up is CRAZY. IT takes for ever. Maybe I am doing it wrong. We do use groups as much as possible too. I would really love it if they would create TAB security. I had always heard they were doing this in E10. NOPE…

1 Like

One way to make “tab security” is to make a customization that is missing the tab… then put this customization as a new option on the menu with its own security… Now you can specify which “custom” version of the screen you want people to use to edit.

1 Like

SOX (Segregation of Duties) requires us to make about 80 versions of 1 Screen with every Role having ability to change something in ex Customer Maintenance… If your sales, everything should be readonly but Territory, If you are Accounting then the Bank tab is for you etc…

I dont see a future with 5000 Customizations :slight_smile: Sure you can start doing it with code. We sha’ll see. Was hoping to leverage Field Security, per Security Group.

1 Like

@hkeric.wci We have successfully restricted part entry form down to individual fields using field security setup back when we were on 9.05.606A, There is no way anyone want to maintain multiple copies of a form customization or large number of lines of code just to achieve the result that field security should accomplish.

It would be good to have the ability to set field level security by user or user group on a global form as well as on a company specific form. Some forms the access to fields will be the same across our companies and in some cases not.

Really hope to get field level security working again similarly to how it has functioned in the past.

Hi @kfierce

This is possible (not sure what version it was introduced) now, at least in 10.1 and 10.2. You can set the field security for all companies or each individual company with this checkbox.

1 Like

The question becomes if I have a button and that button invokes Part Adapters, Part BO’s for the User (in a controlled fashion) will that error out? I dont know how much Field Security breaks… is it just for the UI or will also any Adapter that modifies that Field which runs under the User’s Session break?

Because Adapters / BPMs still carry the Session of the invoking Client / User.