We have non-IT users who would like to create BAQs. When creating a BAQ, I see all tables are available. This became a concern. I reached out to EPICCARE (created a case) asking how to set permissions to allow non-IT users to create BAQs. They responded that I would have to give the user Security Manager permissions. Is this true? If not, how would I be able to customize the access to hide certain tables with information that they should not be privy to?
Field Security Maintenance should prevent users from retrieving data they aren’t supposed to see even in BAQ’s or Dashboards. While we don’t grant BAQ access to users, we do use FSM to restrict who can see/edit certain fields and that extends to BAQ’s and Dashboards.
I don’t believe that you have to give someone Security Manager permissions to make BAQ’s. There’s already an “Advanced BAQ” setting in User Acct Maint. (which allows users to create updatable BAQ’s) which implies that there’s a basic BAQ permission for anyone granted access to BAQ Entry.
I’d set up a test user account and play with it yourself.
Hi John, I had the same idea you did regarding “Advanced BAQ”, but I could not find a “Basic BAQ” permission setting. The next thing I wondered is how to limit and/or select tables they can see to create a BAQ. ALL tables are available for BAQ creation. I gather a supply chain person would want PART specific tables but not need sales or customer related tables.
Another thing to note is when I work on a case with EPICCARE, they sometimes ask for a BAQ of data. How would that be possible if a non-IT person were working on that case? They would not have security manager permissions.
The reason this all came up is that one of our customers, advised our management, that they all create BAQs. I am now wondering how. I was not in on the conversation.
Like I said, I assume users without “Advanced” permissions can create read-only BAQ’s so long as they have access to BAQ Designer.
Epicor doesn’t have table, or even row level, security out of the box. So your supply chain person would be able to (for example) see the LaborDtl table (and the key fields, which in this case are inscrutable integer sequences) but if you secure the other columns they wouldn’t be able to get any real data out of it.
I suppose you could look into adding BPM’s to Ice.BAQDesigner that, say, manipulates GetTableList(). But before you mess with that, you really should set field security, and spin up a user with basic access to the BAQ Designer and see what they can actually do.
Even if they could does not mean they should. From the beginning of our use of Epicor, it was decided that BAQ and Dashboard would be exclusive to IT department. Users needing a specific dashboard we would create for them. The knowledge of fields and relations between tables are often not obvious. And moreover, the naming of the BAQ/DB would have been a nightmare to maintain.
That’s my 2 cents… 
Pierre
5 Likes
The tables will remain in the list, but if you actually try to run the query it will give you and error message if you for territory or field security conflicts.
Great Question @tsantaniello .
I have a number of DB savvy Engineers that i would like to give access to the BAQ creation so they can do Ad-Hoc Querries against the Job tables. However, If i do that i risk them wandering into the Cash Reciepts, or Sales tables.
IMHO Field securty is the wrong tool and can cause unintended issues in other areas.
I wish Epicor would adopt a “Scope” like we have with REST 2.0 where we can define specific tables that “Scopes” have Read Only access to.
DaveO
Honestly, I wouldn’t give users access to BAQ for ad hoc data queries. It’s very easy to bring the system to its knees with IT people building queries, let alone those who don’t understand relational mathematics. If you’re going to Insights this year, maybe you have the team look at one of Epicor’s latest acquisitions: https://grow.com. It’s meant to give users easier access to the data. Others on the list use PowerBI to do the same. This all depends on what kind of data they are looking for: real-time or near real-time but I would prefer it over BAQ access.
3 Likes
Are you talking about bringing the system to its knees developing BAQ’s or just the proliferation of poor performance BAQ’s making the overall experience seem slow?
Seems like it would be fine if people can develop slow BAQ’s for their own private use, but an IT person would have to approve BAQ’s for dashboards or public consumption. Seems like there needs to be a balance between gatekeeping and optimal performance. Some of us only have IT skills because we were allowed to develop them
A Priest, a Minister, and a Rabbi walk into a bar and all create outer joins from Part to PartTran with no selection criteria.
The bartender (who is also a DBA) asks:
“Is this some kind of joke?”
3 Likes
Mr. @Mark_Wonsil : I did watch the recent webinar on Grow.com.
It did seem like a possibility - we do not need “real time” access. However it looked to me like Grow.com is just another version of Phocas? (if i got the name right). I did not grasp why Grow vs Phocas.
DaveO
1 Like
Epicor owns Grow but not Phocas.
You could also create some BAQs and give the users access to EDD to do what they want.
Agreed, and the current trend in the industry is to move that data over to a place where extra security can be enforced and give these “citizen developers” tools that are easier to use than SQL.
The one I heard was from Part to ttPartTran in a PartTran Data Directive …
2 Likes
The other one is an SQL Statement goes into a restaurant, walks up to two tables and asks:
“May I join you?”
1 Like
That is a great point! the user just need to create a recusive situation ( not knowing about it…) and crash the system.
The idea here is to provide training and make them develop maybe on a DEV environment…on a seperate server… have fun etc… then as mentionned, get it approved by IT. So they have all the rights in DEV necessary to develop, but not in the Prod system…
The idea of using PowerBI again they would need to know SQL…more training… more work than just using widgets…
I am barely familiar with Epicor Data Analytics (Phocas) and not at all familiar with Grow. Are they substitutes for each other or just complementary to each other? IIRC, Epicor Data Discovery is home-grown, i.e. not Phocas-based. If that’s correct, does/will Grow replace EDD even if it doesn’t replace EDA?
Phocas has you export data. Grow appears to be a connector model (like PowerBI) but I’m not sure if they host data like Microsoft or just pull from other cloud storage.
EDD runs BAQs, which is basic functionality for Epicor, so I don’t see why one would replace it. I certainly cannot explain why companies do what they do? 
1 Like
This is one of those questions where i want to answer: Don't do it man! because having novice users creating incorrect BAQ links can cause huge performance hits.
Back in the olden days of Vantage 8, there were dozens of ways to crash the system (literally) by writing a bad baq.
In my opinion, only “certified” users should be given this privilege.
3 Likes