I work in a single plant of a multi-national public company. Since corporate moved our plant to Epicor we have been stripped of all ability to build or customize reports and dashboards. I am no stranger to public companies or multi-location security concerns. However, this is the only time no one in my plant could work on reports or build datasets for our location.
What we have been told is allowing us to build BAQs and dashboards would provide us access to sensitive data such as salaries (payroll isn’t in Epicor) and bank account data. It would seem to me that there should be some sort of built-in security to keep a user capable of building reports and dashboards out of sensitive financial or personal records. Even in past lives while working as a DBA, I could not access bank data. I might have been able to pull the fields but the data was encrypted. Is this not the case with Epicor?
What about not being able to build datasets with BAQ’s, but having the ability to customize a dashboard using the existing data that a system admin has pre-built? It seems pretty safe, but we have been denied this ability as well.
Basically what I am finding is our parent company uses security as an excuse not to change. Because I haven’t used Epicor since Vantage 6 I don’t have the knowledge to push back. So I am asking those of you in similar situations how you’ve handled it. It’s becoming a real issue as the turn around time for a minor report or dashboard change from corporate is over 3 months.
Surprisingly, the most restrictive built-in security in Epicor is related to sales territories.
Some big customer must have been burned by a salesman accessing customer and sales info outside of their territory. So now the Territories play a big part in built-in security.
What you might be able to ask Corporate for is to setup some external links to the E10 DB, with security restrictions by table. Then you you could access the Inventory and Produsction info (Parts jobs, PO’s, part trans, etc…) and be insulated from Financial Management stuff like GL AR AP, etc …
If they don’t want to do that, then keep badgering them to make the reports you want.
Epicor BAQs execute on SQL via the IIS Service Account and there is definitely alot of room for improvement needed in Epicor. They are slowly but surely getting better by adding Data Masking etc…
Data Masking Limitations / Tips:
Does not impact security manager users
Can only be used on character fields that are defined up to x(100) (cant use number fields)
Like field security, can’t be used on fields within a primary key
BPMs do NOT show masked data
BAQs do show masked data
When Full Masked access is used, data that is supposed to be masked should not contain the selected mask character
Not the same as SQLs dynamic data masking (DDM) functionality
There isn’t anything at this time that restricts access in a BAQ to specific tables. Also in a Multi-Company Epicor Environment you share the Database with other Companies.
Typically when a large Corporation uses Epicor, there is always red tape, some due to SOX (Segregation of Duties) Controls. Where for example the Developer can DEV, TST but can’t deploy to PRD. A Person who can create PO’s cant Receive the Shipment.
I’ve struggled with that as well in the past, coming from a LLC to a Publicly Traded Company. I went from a multi-hat do-it-all to You can only touch server A.
In all my past experiences, typically a Corporation is trying to Commonize Epicor so when they build a Dashboard they release it to the entire Industry Vertical, doing company-specific customizations and dashboards becomes a pile of Technical Debt that in the long run makes upgrades harder.
Upgrades can break stuff, so all the Customization elements need to be well defined, documented to be upgrade friendly.
Typically a proper process is:
Business Analyst Receives Request
Analyzes it and works with User to proper identify requirements
Development
Testing
Deployment (By Infrastructure)
Writing User Training
Training Users
Applying Securities
Ongoing: Cost of Maintenance / Upgrade / Who Moved My Cheese Arguments
I always say this on the forum. Dont customize for the User. Customize for the Process and Train the Users on a Process. If your User has a good Enhancement idea, then its very likely that the entire Corporation can benefit from it. (Even if its a dashboard)
If a User needs X Data, or a Special Dashboard to do their job then its probably missing for everyone as well.
First, I agree with @hkeric.wci about commonizing Epicor across different functional units so everyone is on the same page.
To the original topic about security in BAQs and Reports: all BAQs (and RDDs as far as I remember) run through Epicor’s security layer. This lets you (or Corporate) define which fields are available, read-only, masked, etc. for each user including power-users who can build BAQs. The security is on the field level, not the table level, but the security is followed even in the BAQ designer.
Using Field Security Maintenance, set the BankAcct.BankRoutingNum field to Read Masked for all users except security managers. I also set the BankName field to None access.
The field I made hidden isn’t available in the BAQ Designer for this user. You can still add it to the query, but it will show blank unless you have access.
But if you do that to 5000 fields chances are it wasn’t built for that and bigger overhead. On a small scale, yes.
When you build Dashboard that was approved to show a portion of financial fields and its masked, now you are managing all day long changes to Data Masking.
I’d rather give the User SQL Access and simply put them in a Group where they can’t access the Financial Tables w/ Readonly. Instead of Masks on Fields for 100s of Tables and each one has 50+ fields. (SQL Replication Database)
Epicor Data Masking is great I use it for stuff like, let’s hide Tax Number or Bank Routing Fields. Just like Field Security. But in Order to use it properly, you must split up your Securities per Local Company.
Company1_CanDoX
Company2_CanDoY
Because typically in Corporate 1 Person sometimes manages 2-3 Companies and in 1 they can see stuff and in others they can’t.
Even @Mark_Wonsil had a great time with re-designing Epicor Security Groups
I worked for a company once that their IT department or at least their local representative used SOX as means to sit back and do nothing, which in turn made it difficult and frustrating for our team to perform our job. In your situation, it sounds like we have a bit of a fifedom happening, which is a shame, people get paid to do their job and promote the ongoing improvement of the business they work for not their EGO…That’s the way I see it anyway.
I tend to agree with @hkeric.wci with regards to the process, but I do have a few suggestions, which by the sounds of the a lot of Epicor experience is being wasted by not providing access to the tools that are required to perform their role, and ultimately make they way people work more efficient.
To prevent access to other company information, Epicor does have external integration so you can in effect have different Epicor companies in different databases. I’ve only seen and read about it and never implemented in the real world.
Secondly, surely to enable you to contribute to the Epicor ecosystem at your company, then possibly asking for a demonstration environment to develop your dashboards and using a subset of your local company data to prove them. You can add additional companies to the Demo database or even create your own, with judicous use of DMT you can create a way to extract and automate the data to move over to your “Demo/Dev” environment. There are a couple of posts around about that. I know Epicor have been working on a tool around the DMT to just do that.
Yes you can do Direct Multi-Company and Service Bus Multi-Company… But if you are already implemented, that is a re-implementation effort of its own. Then you are upgrading not 1 database but 25 and backing up 25 (if you have that many). With MS Service Bus dead being moved to Azure… the future is:
hint: Epicor acquired an EDI Company Recently, Perhaps Multi-Company just becomes EDI
Since Masking was mentioned, I wanted to share notes I had it may be helpful to someone…
Data Masking Tips:
• Does not impact security manager users
• Can only be used on character fields that are defined up to x(100)
• Like field security, can’t be used on fields within a primary key
• BPMs do NOT show masked data
• BAQs do show masked data
• When Full Masked access is used, data that is supposed to be masked should not contain the selected mask character
• Not the same as SQLs dynamic data masking (DDM) functionality
Thank you for all the replies. I have a lot to research regarding masking and Epicor Security.
We have requested a test or sandbox system without sensitive data or even just demo data. The thought was we could create and test BAQs and Dashboards. Then let the corporate BAs validate them. Although we haven’t been outright denied, it has been 6 months and no sandbox.
I agree that in large companies having variations and customization is a problem. But our parent company has been on a company buying spree with companies from a wide range of industries. I don’t think a standard set of reports and dashboards will work across the board. They either need to let us build or get additional resources to complete requests.
It’s been frustrating. We moved to Epicor just over a year ago when we were acquired. Since then our on time, productivity and profits have plummeted. Our job travelers are impossible to read. We lost critical customization from or previous ERP. Inventory is a mess as well. We’ve started to export data to other tools and it has helped identify problems. But this isn’t a good idea and it’s time consuming.
This sounds like this is the real problem?
What if responses to your requests averaged <= 48 hours?
Personally, I’m a fan of using a central person/group for handling query/report/dashboard requests. Partially due to security issues mentioned but mostly… it is more efficient and you end up with more accurate results (I think).
Our job travelers are impossible to read.
Inventory is a mess as well.
We’ve started to export data
What kind of Epicor training have you guys had?
Reason I ask, is that I once lived thru a similar sounding transition
(from DataFlo to the original V8).
Compared to V6, that original V8 version wasn’t so great but… looking back now, I’d still have to say that many of the problems really boiled down to two things. Either a lack of training OR less that 100% “buy in” by many of the critical leaders/users.
sandbox system without sensitive data or even just demo data
Yes, I use a test system with the Education database all the time.
Our training was a bit rushed according to those here when it happened. I came on a shortly after. I will say management is really trying to get Epicor right. But as a purely custom manufacturer there a things corporate wants to make standard, that just do not work for us.
Instead of Masks on Fields for 100s of Tables and each one has 50+ fields. (SQL Replication Database)
