I have a conundrum here. I don’t know for sure if this is since our upgrade to 2025.2 (I think it is, or someone would have yelled) but how do people handle read only field security with fields that need to be defaulted to something other than what Epicor wants it defaulted to?
My specific case is the customer type. I want the customer record to start as prospects. (We don’t use suspects). We have BPM’s in place that set the default, but if you are in one of the security groups that limits you to read only, it won’t let you save the record with the defaulted value and it “goes back” to suspect. How can we set programmatic defaults while still controlling field security?
For this scenario, the BO will do it’s thing and enforce it’s stuff. That being said, you can’t try and override it’s behavior in .Update or .UpdateMaster unless you are planning to override the Base (which you shouldn’t)
Instead, accept that the BO will write to Db with the incorrect value, then in Post, instantiate a transaction, pull the written row from Db.Object, update the field, and Db.SaveObject() it.
So I’m not missing a normal part of how this should work then. Epicor does not have a recommended way for an admin, using a BPM or otherwise, to set a default, that that user has read only permissions to.
We are doing this on get new post processing (before the record is even in the database). I believe it used to work, but then after the upgrade something changed.
Based on changelogs, I think BPM’s run as whatever user triggered them.. so maybe impersonation could get around this? Not sure its any less janky than what @GabeFranco suggested tho
I’ll start by saying we don’t use the CRM module’s task set which I believe may auto-update this column as the customer account progresses?? Not sure if it works that way or not.
What we do is, when the Customer record is first created, everything is wide open. Sales person can set value of fields like territory, salesrep, etc.
Once the record is saved, though, we have a BPM in place that specific fields cannot be changed unless the user belongs to our Sales Management group.
I guess my point is, we don’t use field security to limit access to these fields. We only use a BPM that raises an exception if someone outside of the management group tries to update those fields.
I think I know why the change. Kinetic doesn’t seem to have the concept of “read only” like classic does. And I get why, it’s super easy to mess with the UI in a browser so making those fields read only isn’t actually secure. So they can’t let that go through.
But, we now have no way as admins to set the defaults to what we need.
It’s frustrating to have a feature that Epicor keeps spending money and resources on that we can’t even use because real life doesn’t match their design.
Yep, field security is barely usable, and only under specific, limited situations. And as you know, it doesn’t even have the useful visual component like it had in classic on kinetic screens. Just silently doesn’t save that field last I tried it.
I know this is pain to have to do… but perhaps a simple Kinetic event after AfterGetNew can row-update that column value, even before the initial save?
