Sure, we do create a specific Login and lock it down to the minimum that it needs:
Which I know is still not the most kosher, but is it egregious enough to tell the business they cannot have the feature they want?
My only argument here is there is often no actual alternative besides saying no to the request.
When the request from non-IT people is of a technical nature, I have less trouble saying, âHang on. Whatâs the business problem weâre trying to solve? How can we get there in a way that is easy to maintain, keeps our Cyber Insurance less expensive, and doesnât jeopardize our customerâs intellectual property? What amount of loss are you willing to accept with the requested solution? I mean, is a paper report our only option?â
Exactly, I feel like there was an idea out there to add the ability to do this or add aliased tables that are repeats of tables already included in the RDD.
I may be wrong on this, but I canât think of an instance in which you canât use the normal report data. Specially since they added BAQ RDDs
Brain foggy⌠did they add the ability to put BAQs in out of the box RDDs?
I havenât tried since 24.x so I just tested in 25.1 and canât add a BAQ to a copy of ARForm RDD.
That or add a copy of a table in the RDD already as an alias (i.e. adding InvcDtl again or Customer, etc.)_
Thanks for confirming that Randy.
What I mean is @Randy, sometimes there are some linked tables in an RDD that are linked on a key in say, invcdtl, but I need them to be linked on a different table as well as that table. Maybe I am overthinking it, but thatâs a common scenario I run up against.
The combination of these two gaps is what drives people to hit the db directly. If you could add the same system table twice, and/or you could combine tables and baq data sources within a single rdd, there would never be any reason why you would NEED to hit the db. But unless you want to build system reports from scratch with a baq data source (and who has time for that, especially when its something super complicated like a traveler or invoice?) sometimes there really is no other choice.
I really hope Epicor has it in the roadmap to address this.
From your post to ceiling catâs ears.
Right, I believe this has been the main driver of when weâve hit the db directly. Things like needing to see subordinate Job information on a âparentâ Job Traveler, etc. I donât think we have any truly super critical needs but it comes up a lot in everyday requests.
Same here. Our needs are recursive Lot tracking page for the customer. Only solution I can think of is to pre-summarize in a higher record and then expand it in the report. 
Hopefully Bold Reports offering will be full featured so you can combine any number of data sources including direct REST.
Adding some functionality contextâŚ
Documentation is here. Theyâre delightfully adequate! Surely Epicor docs will direct users to these docs. Maybe bookmark them just in case. 
Thereâs also a free trial if you want to take the future functionality for a spin.
WebAPI is a data connection option, if a supporting package is installed. Supporting HTTP calls comes with security and compliance considerations, proceed accordingly.
Anyhow, this is how talking to REST works in BoldReports.
Dunno if thatâs relevant to RDL reporting though. BoldReportâs RDL compatibility cuts off at 2008 R2. Supporting web API as a data source would require extending RDL. But that could have happened? Maybe itâs spelled out in the docs, surely a free trial would answer these questions and more, I just havenât had the time to dig that deep.
My understanding is Bold Reports calls everything âRDL reportsâ. they extend the RDL schema for things like webAPI without breaking compatibility using custom rd: namespaces. BR uses these, SSRS ignores them.
WebAPI is included with BR Embedded. Assuming Epicor is hosting the viewer & designer, itâs simply a nuget they would register if they want us able to use it.
Our hope is they donât stunt the offering they embed so we get the full capabilities of BR with respect to mixing datasource types including at least Epicor webAPIs.
Shucks, why not even 3rd party REST. Its just JSON.
