Reporting module
Reports that read the system, not an export of it
A business-intelligence tool inside the eRA system, reading a real-time replica so a heavy query never competes with someone trying to submit.
The failure this replaces
The number in the report and the number in the system disagree, and nobody knows which is right.
It starts reasonably. Reporting is slow or restricted, so somebody exports to a spreadsheet once a week. Then a second spreadsheet appears with a different filter, then a dashboard built on the first one, and within a year the institution has three answers to how many proposals went out last quarter.
The tell is what happens in the meeting: everyone waits while someone checks the number against the system by hand. That is not a reporting problem, it is a freshness problem, and no amount of chart-building fixes it.
What it does
Ask it, schedule it, send it somewhere else
A replica, so reporting never fights submission
The production database is replicated to a reporting database in real time. A heavy query on the last day of a federal deadline week does not compete with the person trying to submit — which is the specific reason reporting is usually restricted somewhere else.
Drag-and-drop, or SQL if you would rather
Build a report by dragging fields, or write the SQL. The interface exists so a research administrator can answer their own question without learning the schema; the SQL exists so your institutional research team is not held back by an interface.
130+ reports delivered ready to run
Across every module, with data sets provided for building new ones and several comprehensive dashboards out of the box. The point of a delivered report is that the first useful answer arrives before the configuration project does.
Dashboards assembled by the person who wants them
Charts, tables, input fields and custom filters, drilled into in real time and shared with other users. Given the permissions and the guide, that is a user task rather than a ticket to a technical expert.
Scheduled, and emailed
Reports run on a schedule and arrive in an inbox. A monthly report nobody has to remember to run is a monthly report that actually gets read.
Data in, and data out
Pull financial data in for budget-to-actuals reporting, and push the reporting database out to your data warehouse or third-party tools. Reporting is a place data passes through rather than a place it stops.
Why it is not a separate purchase
A report is only as current as its distance from the record
Every question worth asking in research administration crosses modules — proposals against awards, compliance against funding, this year against the last five. A reporting tool bolted on from outside can only answer those on whatever it was last given.
Streamlyne Reporting sits inside the system and reads a replica of the live database, so the answer is current and the drill-down goes all the way to the record. What leaves for your warehouse is the same data, on your terms.
- Real-time replicaReports never compete with submissions
- 130+ delivered reportsAcross every module, ready to run
- DashboardsCharts, filters, drill-down, shared between users
- SchedulingRecurring reports that arrive without being remembered
- Warehouse exportPush out to third-party tools; pull financials in
Questions
What institutional research asks
Is reporting a separate product?
No. Streamlyne Reporting is a business-intelligence tool inside Streamlyne Research, tightly integrated with it, so reports read live records rather than an export somebody remembered to refresh. That integration is the whole point — a report that is a day old is a report people check against something else before they trust it.
Will running reports slow the system down for everyone else?
It should not, and the architecture is the reason: the production database is replicated in real time to a separate reporting database, and reports read the replica. This is worth asking every vendor, because where it is not true the practical consequence is that reporting gets restricted to off-hours by policy.
Do we need SQL to build a report?
No. The interface is drag-and-drop and was built so someone can add and remove columns, format data, filter, sort and group without knowing the underlying schema. SQL is available for people who want it, which is usually institutional research rather than the sponsored programs office.
How many reports come with it?
More than 130 out of the box across all modules, plus data sets to build from and several default dashboards. Expect to build your own eventually — every institution's real questions are its own — but not on day one just to see anything.
Can reports be scheduled and sent out?
Yes, with emailing. It matters more than it sounds: the reports that change behaviour are the recurring ones, and a recurring report that depends on someone remembering to run it degrades to nobody running it within about two quarters.
Can we get the data into our data warehouse?
Yes — data can be pushed out of the Streamlyne Reporting database to a warehouse or third-party tools, and financial data can be pulled in for budget-to-actuals reporting. If your institution has a central analytics team, that is usually the conversation that matters more than the dashboards.