Has Anyone Automated Report Creation Triggered via Service Request? Need Guidance for Designing This

[Amey Kapse]

Hi Everyone,

I’m looking for guidance on implementing an end‑to‑end automated report creation process in ServiceNow, where the user raises a Service Request, and based on the inputs provided, a report is automatically created in the Reports module and delivered back.

Before designing the solution, I want to understand if anyone has already implemented something similar and what best practices to follow.

---

What I Want to Achieve

1. User submits a Service Request

The request should collect all the required parameters to build a report dynamically, such as:

• Report type (bar/pie/list/etc.)
• Table name
• Columns/fields to display
• Filter conditions / date ranges
• GroupBy or aggregation options
• Format required: PDF / Excel / Both
• Recipients or delivery method (e.g., email, attachment on RITM)
• Whether they want a one‑time report or scheduled report

---

2. Automation should handle the rest

Once the request is submitted, the system should:

• Validate user inputs
• Dynamically create a Report record in the Reports module
• Apply user‑provided filters and columns
• Generate the report output
• Export it (PDF/Excel)
• Deliver it to requester or stakeholders
• Log status and errors

---

Looking for Community Guidance on These Points

1. What inputs should I capture in the Service Request?

Is there anything important I’m missing beyond:

• Table
• Filters
• Columns
• Report type
• Output format
• Delivery method
• Schedule frequency (optional)

Would love recommendations from your real‑world implementations.

---

2. How do I programmatically create a report in the Reports module?

Has anyone used:

• Glide APIs for report creation
• Script Includes to build report definitions
• Dynamic filter creation based on user input

Any code examples, reference docs, or tips would be extremely helpful.

---

3. Ideal technical architecture for this automation

Some options I’m considering:

• Catalog Item → Flow Designer → Script Action → Script Include
• Catalog Item → Subflow calling Report Builder Script Include
• Scripted REST API (optional) for reusable report generation
• Using sys_report and report_source tables programmatically

If you've implemented a scalable design pattern, please share your approach.

---

4. Best practices I should follow

Especially for:

• Performance (queries, large datasets)
• Security (restrict access to sensitive tables)
• Reusability (config files, templates)
• Avoiding long‑running script issues
• Preventing malformed/unsafe user filters
• Managing PDF/Excel export limitations

---

5. Challenges I should prepare for

Some areas I’m unsure about:

• Script execution timeouts during export
• Complex filters provided by end users
• PDF template formatting
• Dynamic field selection
• Permission issues when users request data from restricted tables

Your lessons learned would be extremely valuable.

---

Request

If anyone has:

• Implemented similar on-demand report automation
• Built dynamic report generators
• Programmatically created ServiceNow reports
• Advice on the best approach to architect this

…I would really appreciate your guidance, examples, or documentation references.

Thanks in advance!

[lauri457]

Have you considered just letting users build the reports in the native tool? Instead of users putting all these requirements in the report builder themselves and getting instant visual feedback they have to try and imagine the data visualization when building it via a form.

It is not an extremely complex tool to use (PA or legacy reporting both) and is meant for self-service in itself. I don't think you should build a proxy catalog item for it. It will end up being a bad experience for the devs and users and be a huge waste of resources that could be used elsewhere. Use the build time to train users instead

[Amey Kapse]

Thanks for the suggestion — and you're right, native reporting is the ideal option. We even provide a user guide within the catalog item to help users build reports on their own.

However, in our environment:

• Many users still don’t have permissions to the required tables.
• The report requests are mostly standard patterns, so automation would save a lot of manual effort.
• Most requesters simply want the final output, not to build the report themselves.
• We already have a catalog item in use, so enhancing it for automation seems like a practical next step.

So, while self‑service is encouraged, we’re still evaluating automation because of these real‑world constraints.

[Tanushree Maiti]

Hi @Amey Kapse  , 

I believe Report generation should be a control process means when someone starting with report creation he/she should be Define clear reporting requirement.

Here is ServiceNow Reporting Best Practices 

When you will automating it , you need to make it flexible so that anything /everything (column) of a table  they can select ..it is kind of out of control and report requirement is defined by End User !

Impact on Platform:

• Platform Performance Impact: Running heavy, automated reports on large tables can significantly slow down database queries, causing performance bottlenecks for users.
• Maintenance & Technical Debt: Custom reports often require specialized knowledge ,If not properly Configured/managed, these can create high technical debt.
• Security & Accuracy Risks: Automated reporting without proper monitoring can result in misconfigured filters, leading to inaccurate data distribution or sending sensitive, unauthorized information.