DEV Community: Razi Syed

Scheduled PDF and Excel report emails in ASP.NET Core with Quartz.NET

Razi Syed — Thu, 08 Oct 2026 22:35:01 +0000

By Razi Syed. Sample code: github.com/dotnetreport/dotnetreport-scheduled-reports

The moment users can build their own reports, the very next request is "can it just email me this every Monday at 8?" It sounds like a checkbox. It is actually five separate problems, and teams that treat it as a checkbox tend to discover them one at a time in production:

Scheduling — cron expressions, and evaluating them correctly against the last run so a missed tick doesn't fire twice or not at all.
Time zones — "8 a.m." means 8 a.m. to the user, not to your server in UTC.
Rendering — a report on screen is HTML; an email wants a PDF or an Excel file that looks right.
Security with nobody logged in — the job runs at 6 a.m. with no HTTP request, no cookie, no claims. Whatever row-level security you applied interactively has to apply here too, or your nightly email leaks data.
Hosting — background jobs inside a web process die when the process idles, and duplicate when you scale out.

This article walks through how the scheduler that ships with Dotnet Report (which I work on — disclosure) handles each, because the design decisions are the useful part even if you build your own. It's a Quartz.NET job, so if you know Quartz the shape will be familiar.

The design in one paragraph

A single Quartz job starts with the app and polls every 60 seconds. Each pass it loads the saved schedules, and for each one evaluates the schedule's cron expression, in the schedule's own time zone, against the schedule's recorded last run to decide if it's due. When it is, it renders the report — carrying the schedule's saved user, tenant and data filters so security holds — as PDF, Excel, or a link, emails it via SMTP, and records the run. That's it. Nothing clever; the value is in getting the five details right.

1. Starting the job

Enabling it is one line after the app is built, plus telling the job the app's own public URL:

var app = builder.Build();

JobScheduler.Start();
JobScheduler.WebAppRootUrl = builder.Configuration["App:PublicUrl"] ?? "https://localhost:5001";

Under the hood Start() builds a durable Quartz job and a simple trigger that repeats every 60 seconds forever:

IJobDetail job = JobBuilder.Create<DotNetReportJob>()
    .WithIdentity("DotNetReportJob")
    .StoreDurably()
    .Build();

ITrigger trigger = TriggerBuilder.Create()
    .WithIdentity("DotNetReportJobTrigger")
    .StartNow()
    .WithSimpleSchedule(s => s.WithIntervalInSeconds(60).RepeatForever())
    .Build();

await scheduler.ScheduleJob(job, trigger);

Why poll every minute instead of registering one Quartz trigger per user schedule? Because user schedules are data — created, edited and deleted from the UI all day — and a single polling job that reads them fresh each pass is far simpler to keep consistent than a fleet of triggers you'd have to mirror on every change. A one-minute resolution is plenty for report delivery.

2. Cron + time zones, evaluated against last run

Each schedule stores a cron expression and a time zone id. The job resolves the zone, parses the cron with Quartz's CronExpression, and asks for the next occurrence after the last run — converting the stored last-run into the user's zone first so "after 8 a.m. Monday" is evaluated where the user lives:

TimeZoneInfo targetTimeZone = !string.IsNullOrEmpty(timeZoneId)
    ? TimeZoneInfo.FindSystemTimeZoneById(timeZoneId)
    : TimeZoneInfo.Local;

var chron = new CronExpression(cron);
var lastRun = !string.IsNullOrEmpty(lastRunFromDb)
    ? Convert.ToDateTime(lastRunFromDb)
    : DateTimeOffset.UtcNow.AddMinutes(-10);

if (!string.IsNullOrEmpty(timeZoneId) && !string.IsNullOrEmpty(lastRunFromDb))
    lastRun = TimeZoneInfo.ConvertTime(lastRun, targetTimeZone);

var nextRun = chron.GetTimeAfter(lastRun);

Two details worth copying. Evaluating against the last run (not "now") is what makes the job robust to restarts: if the process was down at 8:00 and comes back at 8:03, the next-run-after-last-run is still 8:00, so it fires once, late, instead of never. And a schedule can carry an optional start/end window so "every Monday, but only during the audit period" works without the user having to remember to delete it.

3. Rendering PDF and Excel

Users choose a format per schedule: PDF, Excel, Excel-Sub (with sub-totals expanded), or Link.

PDF is rendered by loading the report's print view — {WebAppRootUrl}/DotnetReport/ReportPrint — in a headless browser (PuppeteerSharp) and printing it, with the schedule's page size and orientation. That's why WebAppRootUrl must be a URL the job can actually reach; on a dev box https://localhost:5001 is fine, in production it's your public host. Rendering the real HTML view means the PDF matches what the user sees, charts included.

Excel is generated directly with EPPlus from the report definition — columns, grouping, sub-totals, pivots — and if the report has a chart, the chart is rendered to an image and embedded in the workbook. Dashboards with several reports are combined into one PDF or one multi-sheet workbook.

Link just emails a link to the live report, for people who'd rather open it in the app.

4. Security when nobody is logged in

This is the one that bites teams who bolt scheduling on afterwards. Interactive reports are filtered by the current user's context — in Dotnet Report that's GetSettings(), which passes the user id, tenant id and a DataFilters object the engine appends to every query for row-level security (I covered that in Multi-tenant reporting in ASP.NET Core: row-level security your users can't bypass).

At 6 a.m. there is no current user. So each schedule saves the user's id and DataFilters with it, and the job passes exactly those into rendering:

fileData = await DotNetReportHelper.GetPdfFile(
    JobScheduler.WebAppRootUrl + "/DotnetReport/ReportPrint",
    reportId, reportSql, connectKey, reportName,
    schedule.UserId,                                  // who scheduled it
    clientId,                                         // their tenant
    JsonConvert.SerializeObject(schedule.DataFilters), // their row-level filters
    pageSize: schedule.SelectedPageSize,
    pageOrientation: schedule.SelectedPageOrientation);

The emailed PDF is therefore filtered identically to what that user would have seen in the browser. The principle generalizes: snapshot the security context at schedule time and replay it at run time. Never render a scheduled report as an anonymous or admin identity and hope the filters come along.

5. Email

Delivery is plain SmtpClient / MailMessage using an email section in configuration:

"email": {
  "fromemail": "reports@yourapp.com",
  "fromname": "Your App Reports",
  "server": "smtp.yourprovider.com",
  "username": "smtp-username",
  "password": "smtp-password"
}

Keep the password in user secrets or environment variables. If you'd rather use a transactional email API than SMTP, this is the one seam to swap.

Hosting: the two rules

Keep the process alive. The job runs inside the web app. IIS idles app pools by default; set idle timeout to 0 or enable Application Initialization, and on Azure App Service turn on Always On. Otherwise the scheduler quietly stops when the site goes quiet — usually exactly when nightly reports should fire.

Run one scheduler. If you scale out to several instances, run the job on a single designated instance (a config flag or a leader-election check is enough). Otherwise every instance polls, every instance decides the 8 a.m. report is due, and your users get three copies. Recording the last run promptly narrows the window but does not eliminate it; one scheduler does.

Wrap-up

"Email me this every Monday" decomposes into scheduling against last-run, time-zone-aware cron, real rendering to PDF/Excel, replaying the user's security context with no user present, and keeping exactly one live scheduler. The sample host, Program.cs and config are in the repo: dotnetreport/dotnetreport-scheduled-reports. If you haven't set up the report builder yet, start with Add self-service ad hoc reporting to an ASP.NET Core app.

Razi Syed builds Dotnet Report, an embedded self-service reporting platform for .NET whose report-builder front-end is source-available on GitHub. He writes about adding reporting and analytics to SaaS products without rebuilding them from scratch.

Multi-tenant reporting in ASP.NET Core: row-level security your users can't bypass

Razi Syed — Wed, 30 Sep 2026 11:36:45 +0000

By Razi Syed. Sample code for this article: github.com/dotnetreport/dotnetreport-multitenant-rls

If you run a multi-tenant SaaS product on .NET, you have already solved tenant isolation for the parts of the app you wrote. Every query your code issues carries a WHERE TenantId = @tenant, or a global query filter in EF Core does it for you, and you sleep fine.

Then a customer asks for reporting. Not a fixed set of reports — self-service reporting, where their analysts pick tables and columns, group and filter however they like, and build dashboards without a ticket to your team.

And now you have a problem, because the thing that made isolation easy — you write the query — is gone. The user writes the query. If isolation is something your code adds at the call site, there is no call site anymore.

This article walks through the pattern I use to make row-level security a property of the reporting engine rather than of any particular query, so that it applies to every report a user builds, from context the user cannot change. The examples use Dotnet Report, an embedded report builder for .NET that I work on (disclosure up front), but the shape of the solution — a single server-side context method plus engine-applied filters — is what matters, and it transfers to any reporting layer that gives you the same hooks.

Why "just add the WHERE clause" stops working

Three things go wrong once users author their own queries:

There is no fixed query to modify. A user can join Orders to Customers to Regions in an order you never anticipated. A filter that only knows about Orders misses rows that leak through the join.
Client-side filtering is not security. Anything applied in the browser — hidden columns, default filters, "don't show tenant X" — is one DevTools session away from being removed.
Scheduled and exported reports run with nobody logged in. If isolation depends on the current HTTP request, a nightly emailed PDF has no request and therefore no isolation.

So the requirements are: the filter must be applied server-side, on every table that carries a tenant column, for every query path (interactive, export, scheduled), from trusted context the user cannot forge.

One method, every request

Dotnet Report routes every call from the report builder through a single server-side method, GetSettings(), on the API controller the NuGet package installs. Whatever that method returns is sent to the reporting engine with the request. The three properties that matter for multi-tenancy are:

ClientId — the tenant. Scopes reports, folders and dashboards so tenants don't see each other's saved work.
UserId and CurrentUserRole — the user and their roles, for ownership, sharing and role-based access.
DataFilters — row-level security. A filter the engine appends to every generated SQL statement.

That last one is the key. DataFilters is an anonymous object whose property names are column names and whose values are the allowed values:

settings.DataFilters = new { TenantId = "42" };

The engine turns that into, in effect,

... AND [Table].[TenantId] IN (42)

for every table in the query that has a TenantId column — which is exactly what solves problem #1 above. Join Orders to Customers to Regions; if all three carry TenantId, all three get filtered.

If you need to be explicit about a table, use the Table__Column form (double underscore), and you can combine several filters:

settings.DataFilters = new
{
    Orders__TenantId    = "42",
    Customers__TenantId = "42",
    RegionId            = "3,7"   // comma-separated -> IN (3,7)
};

Drive it from claims, never from input

The values above are hard-coded, which is fine for a demo and unacceptable for production. The whole point is that the tenant comes from context the user cannot change — and in ASP.NET Core that means claims on the authenticated principal, issued by your sign-in code after you verified who they are.

Here is the middle of GetSettings() after the change. (The token/config lines at the top of the installed method stay as they are; the full method is in the sample repo.)

var user = User as ClaimsPrincipal;

// The tenant this user belongs to. Issued at login by YOUR code.
var tenantId = user?.FindFirst("tenant_id")?.Value ?? string.Empty;

// Scopes saved reports, folders and dashboards to the tenant.
settings.ClientId = tenantId;

// Scopes ownership and sharing to the user.
settings.UserId   = user?.FindFirst(ClaimTypes.NameIdentifier)?.Value ?? string.Empty;
settings.UserName = user?.Identity?.Name ?? string.Empty;

// Roles drive role-based access to reports and folders.
settings.CurrentUserRole = user?.Claims
    .Where(c => c.Type == ClaimTypes.Role)
    .Select(c => c.Value)
    .ToList() ?? new List<string>();

// Row-level security: appended to EVERY generated query, server-side.
settings.DataFilters = new { TenantId = tenantId };

And the sign-in side, which is the only place the tenant is ever decided. This is a plain cookie-auth example; with ASP.NET Core Identity or OpenID Connect the mechanism is the same — you add the claim when you build the principal:

var claims = new List<Claim>
{
    new(ClaimTypes.NameIdentifier, userId),
    new(ClaimTypes.Name, userName),
    new("tenant_id", tenantId),      // looked up from YOUR user store, not from the request
};
claims.AddRange(roles.Select(r => new Claim(ClaimTypes.Role, r)));

var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
await http.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity));

Notice what the user cannot do now. They can build any report they like, join any tables, add any filters — and every query still ends with a tenant clause they never see and cannot remove, because it is added on the server from a claim that only your login code can issue.

What about exports and scheduled reports?

This is where the "single method" design pays off a second time. Exports go through the same context. Scheduled reports are more interesting: when a user schedules a report to be emailed nightly, the schedule saves the user's DataFilters alongside it, and the background job renders the report with those saved filters — so a PDF that lands in an inbox at 6 a.m. is filtered exactly as it would have been in the browser, with nobody logged in. Isolation doesn't depend on an HTTP request existing.

Cases you'll hit in practice

A user who spans tenants. Support staff or a parent-company admin may legitimately need several tenants. Issue a claim listing them and pass the comma-separated value — "1,2,3" becomes IN (1,2,3). Isolation is still enforced; it's just enforced to a set.

Restrictions beyond tenant. A regional manager should see only their regions within their tenant. Add a second filter from a second claim: new { TenantId = tenantId, RegionId = regionIds }. Filters compose.

Tables without a tenant column. Lookup/reference tables (countries, currencies) don't need filtering, and a filter keyed on a column they don't have simply doesn't apply to them. The rule is: any table that does carry tenant data must have the tenant column, or it can leak. That's a schema discipline you need regardless of reporting tool.

Admin capabilities. Who can enter the builder's admin mode or the schema setup page is also claim-driven (AllowAdminMode, AllowSetupPageAccess), so you gate those the same way you gate everything else.

Testing it

Do the boring test and do it every release: two users in two tenants, each builds the widest report they can — every table, every join — and each confirms zero rows from the other tenant and zero visibility of the other's saved reports. Then schedule one of those reports, receive the email, and check the PDF. If all three pass, your isolation is a property of the engine, not of your vigilance.

Takeaways

Self-service reporting removes the call site where you used to add WHERE TenantId = …. Isolation has to move into the engine.
Put tenant, user and roles into a single server-side context method, sourced from claims, and have the engine append the filter to every query — including joins, exports and scheduled runs.
Never hard-code tenant values; never trust anything from the client for this.

The complete GetSettings() and a Program.cs that issues the claims are in the sample repo: dotnetreport/dotnetreport-multitenant-rls. If you're starting from zero, my earlier post, Add self-service ad hoc reporting to an ASP.NET Core app, and the quickstart repo get the report builder running first.

Add self-service ad hoc reporting to an ASP.NET Core app (without writing every report yourself)

Razi Syed — Wed, 23 Sep 2026 18:51:20 +0000

By Razi Syed. Sample code: github.com/dotnetreport/dotnetreport-aspnetcore-quickstart

Every line-of-business app I've worked on eventually grows a Reports folder, and every one of those folders tells the same story. The first report was a nice Razor page with a grid. The tenth had four query-string parameters and an Excel export someone bolted on. By the thirtieth, "can you add a column to the sales report" was a two-day ticket, and the backlog of report requests was longer than the backlog of actual features.

The fix is not a better Reports folder. It's letting the people who want the reports build them — inside your app, over your data, without you in the loop. That's what a self-service (ad hoc) report builder does, and this article shows how to embed one in an ASP.NET Core app in a few steps.

I'll use Dotnet Report, which I work on (so, disclosure), because its integration is a NuGet package plus a few lines of config and I can show real code. The steps — install, configure, register services, expose your schema, hand it to users — are what any embedded builder needs.

What "self-service" actually means here

Concretely, after this is wired up, a non-developer in your app can:

pick tables and columns from the ones you've exposed (not raw SQL — a guided picker)
filter, group, sort, aggregate, and add sub-totals
turn the result into a chart or a dashboard
drill down into grouped rows
export to Excel/PDF, or schedule it to be emailed

And you never write those reports. You expose the schema once and get out of the way.

Step 1 — install the package

dotnet add package DotnetReport

That's for .NET 6+. Legacy .NET Framework apps use DotnetReport.Mvc (MVC) or DotnetReport.aspx (Web Forms). The package drops in the report builder's controllers, Razor views and scripts; they live in your project, which means you can restyle them to match your app.

Step 2 — configuration

The builder needs three tokens from a Dotnet Report account (there's a free tier) and a connection string to the database users will report on. Add to appsettings.json:

{
  "dotNetReport": {
    "accountapiurl": "https://dotnetreport.com/portal/api",
    "apiurl": "https://dotnetreport.com/api",
    "accountApiToken": "YOUR-PUBLIC-ACCOUNT-API-TOKEN",
    "dataconnectApiToken": "YOUR-DATA-CONNECT-API-TOKEN",
    "privateApiToken": "YOUR-PRIVATE-API-TOKEN"
  },
  "ConnectionStrings": {
    "ConnectionKey": "Server=.;Database=YourDb;Trusted_Connection=True;TrustServerCertificate=True;"
  }
}

Two notes worth stating plainly. First, the connection string name is ConnectionKey. Second, don't commit real tokens — put them in user secrets or environment variables:

dotnet user-secrets set "dotNetReport:privateApiToken" "..."

Step 3 — register the services it depends on

The report builder is plain MVC: controllers, Razor views, and jQuery/Knockout scripts. So it needs the things any MVC feature needs, plus session (it keeps the user/role context there) and an HttpClient to talk to the reporting service.

var builder = WebApplication.CreateBuilder(args);
var services = builder.Services;

services.AddControllersWithViews();
services.AddHttpClient();
services.AddHttpContextAccessor();
services.AddSession(o =>
{
    o.IdleTimeout = TimeSpan.FromHours(8);
    o.Cookie.HttpOnly = true;
    o.Cookie.IsEssential = true;
});

// Any auth works — the report routes are [Authorize]-protected.
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(o => o.LoginPath = "/Home/Login");

var app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();      // the builder's scripts and CSS
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseSession();          // before endpoints that read session
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");

app.Run();

If you already have an app, you almost certainly have most of this; the additions are usually just AddHttpClient, AddHttpContextAccessor, AddSession/UseSession. Order matters in the middleware pipeline: routing, then auth, then session, then endpoints.

Step 4 — expose your schema

Run the app and open /dotnetsetup. This is a developer/admin screen: it connects with your ConnectionKey string, lists every table and view in the database, and lets you choose which ones end users may report on, with friendly names.

This is the one design decision that deserves thought. Expose views rather than raw tables where your schema is normalized or messy — a vw_SalesByCustomer view that already joins and names things sensibly makes users successful, whereas dumping 200 raw tables at them does not. You are curating a reporting surface, not opening the database.

Step 5 — hand it to users

Open /dotnetreport. That's the report builder. Users pick from the tables you exposed, build, chart, save to folders, share, export and schedule. Link to it from your app's navigation and you're done with the integration.

The next two things you'll need

Getting the builder on screen is the easy part; two follow-ups matter in real apps.

Scope it to the current user and tenant. Out of the box the builder doesn't know who your user is. A single server-side method, GetSettings(), is where you pass the current user id, tenant id, and roles — and, crucially, row-level-security filters the engine appends to every query so users only ever see their own rows. I wrote that up separately with code: Multi-tenant reporting in ASP.NET Core: row-level security your users can't bypass.

Turn on scheduled delivery. Users will immediately ask for "email me this every Monday." The package ships a Quartz.NET job for that; enabling it is one line plus SMTP config — see the scheduled reports sample.

When you shouldn't do this

Honest scoping helps: if you have three fixed reports that never change, a report builder is overkill — write the three Razor pages. Self-service earns its keep when the variety of report requests is the problem, when different customers want different views of the same data, or when you're shipping reporting as a feature to your own customers in a SaaS product. That last case is where it pays off most, because you're turning an endless internal backlog into a capability your users own.

Wrap-up

Install the package, add the config, register controllers/session/HttpClient, expose a curated schema at /dotnetsetup, and point users at /dotnetreport. The working host, sample config and a .gitignore that keeps tokens out of git are in the repo: dotnetreport/dotnetreport-aspnetcore-quickstart.