Do you let users create/run BAQs or is this limited to a specific group?

Do other companies let users create/run their own BAQs or do you limit access to specific individuals who create the BAQs with Dashboards so the users can run?

We have many users that create/run their own BAQs and some that open tickets for our IT team to create but they run. We have very few dashboards. I am being told by Epicor Support that most companies designate certain users to create the BAQs then add them to dashboards. Curious if this is true or Epicor Support BS?

Asking as we recently upgraded to 2023.1.8 and got a look at the new Kinetic BAQ menu :scream: One item that is missing on the kinetic menu is the ability to set the “Rows to Return” which our users use frequently when running BAQs. The “All” default only returns 10,000.

Epicor Support suggested putting the BAQ(s) into a dashboard(s) or setting the Execution Setting “RemoveTestRowLimit”. They also thought I should add an “Epicor Idea” to allow the ability to set “Rows to Return”…something we have in Classic and they took away in Kinetic! To me a “great idea” would be to stop going backwards as Kinetic is hard enough to sell to our users!

It is absolutely true there are very very few users who should have BAQ permissions (IMO).

A poorly setup BAQ without some basic knowledge of SQL and relationships can bring your system to its knees even with rail guards in place.

3 Likes

@dgross I don’t even run BAQs in my production system and no users have access to them.

I have a few that I grant that access in test and if they want their baq made into a dashboard for production I review it and then make the dashboard for them.

Preach it! I am clinging to the classic Epicor like the last piece of floating debris after the Titanic sank.

Jack Dawson GIF by Titanic

Yea, keep your list of BAQ users short and sweet. By that I mean don’t let everyone create BAQs. If users are creating them regularly then they are probably duplicating effort. Find out what they keep creating BAQs for and make a couple of flexible BAQs into dashboards that can cover the needs of multiple groups.

Unless you have strict Field Security in place, and LOTS of it, anyone with access to the BAQ program can see everything in the database. All they have to do is add a table to a query and they can see everything in it. Any table, any field.

From a security standpoint, you have none.

Users (and to me that term signifies anyone who is not a Security Manager-level administrator) should only have access to dashboards.

1 Like

It is there , look at the title
image

It is there but you cannot enter a value like you can in Classic. You have an option of All, 10, 50, 100. All only returns a max of 10,000.

and how many do you need?

Aside from Application Studio, admin and tool menus were the last to be converted to Kinetic. They will probably be the last to be fixed to the point of classic functionality. I’m fine with that as long as the more common user screen laand functions continue to be improved.

Until then, all my development work is going to be done using classic screens (BAQs, BPMs, Report Style, Data Definitions, Menu Maintenance, etc). The Kinetic versions of these screens are beta novelties as far as I’m concerned and I’ll only use them if access to the Smart client is flat out unavailable.

BAQ development should be limited to system admins and trained analysts with the highest trust level in your organization. As others have stated, access to build BAQs is giving the user unrestricted access to the entire database.

4 Likes

:two_hearts:

2 Likes

Well if I said All, I want all of them :rofl:

they are all within 10k limits. Is it not enough? I thought the problem here is that user return too many rows and kill the server. But as in classic you can remove that limit in execution settings.

But I would not want to show millions of rows in the browser ever.

I realize you asked about BAQ (and I agree with limiting users), but I was always more concerned with granting access to DMT. Does anyone keep a tight control on DMT?

Also very few and only templates I build and test.

Yes, DMT is at least as dangerous as BAQ, probably more. With DMT you can incorrectly update or even delete thousands of records if you don’t know what you are doing.

2 Likes

DMT technically only lets you screw up records that you’re already allowed to screw up in the standard client. Just faster.

Not quite it doesn’t respect menu security so if you want to make some new Gl accounts and you don’t have process security then :poop::boom::boom::boom::boom::boom:

Post invoices? Why not? Make some payments? Ya bet (let me know when and I’ll send you my ACH details :joy::joy:)

2 Likes

Nope, menu security still applies to DMT.

We tried letting a few of our “super users” create their own BAQs after some training but quickly took it away once we saw they just don’t have the SQL knowledge/skills to create proper joins, etc. They wouldn’t necessarily know if they are getting bad data or not. So only IT members create and run BAQs at our companies.

For DMT, it’s an even smaller group of us within IT who have access to this tool. We’ll export whatever data the user is looking for into the template format, send it to the user to make updates/adds, and then send it back for us to test and then run in our production system.

1 Like

If you have all the necessary Dashboards and Reports tailored to the business’s needs, the reliance on a BAQ should diminish. If one still finds the need for it, it likely indicates a requirement for a new Report or Dashboard, or additional Epicor functional training such as which Trackers or Reports can retrieve the same information. The same applies to PowerBI.

In a previous company, we provided training to Super Users, but none of them eventually managed to create their own BAQs; it seemed too complex for them.

Even after decades of experience working with Epicor Data, many of us still encounter errors or difficulties in ensuring the accuracy of the data we extract. Consider a user who pulls financial data, assuming it’s correct, but overlooks the Discount Column, resulting in the reporting of inaccurate Sales Data.

It gets even complicated for Jose after countless hours of experience.

I would limit it to Developers, IT, Business Analysts.