DEV Community: Razi Syed

Role-based access to reports and folders in ASP.NET Core: users, roles and admin claims

Razi Syed — Tue, 03 Nov 2026 14:14:10 +0000

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

Once users can build and save their own reports, a second question shows up almost immediately: who gets to see which report? Finance wants a "Payroll by department" report that the rest of the company never sees. A team lead wants to share one report with their team, read-only. Support wants a handful of people to be able to fix everybody's broken reports. And someone has to be able to change the reporting schema itself, which is a very different permission from "can edit a report".

If you model all of that as one IsAdmin flag, you end up either locking users out of the thing you built for them, or handing everyone the keys. This article walks through how I separate those concerns in ASP.NET Core using the role and claim hooks in Dotnet Report (which I work on — disclosure). The pattern carries over even if you build your own report builder: identity comes from the server, permissions are data on each report and folder, and admin powers are claims, checked on the server.

It builds on the previous two articles: adding the report builder and multi-tenant row-level security. Row-level security decides which rows a user sees. This article is about which reports, folders and dashboards they see, and what they can do with them.

Three separate layers

It helps to name them before writing any code:

Who is this user? User id, tenant id, and their roles. This comes from your auth cookie or token, never from the browser.
What can they do with this report or folder? Manage it, view it only, or delete it. Each one can be granted to specific users, specific roles, or a tenant. This is data saved with each report, folder and dashboard.
Can they step outside the normal rules? Admin mode (manage reports and dashboards for all users) and the setup screen (change the reporting schema). These are claims on the user, and they should be rare.

Layer 1: identity in `GetSettings()`

Everything the report builder does goes through one server-side method, GetSettings() in DotNetReportApiController. That's where you translate your auth into the reporting context:

var user = User as ClaimsPrincipal;

settings.ClientId = user?.FindFirst("tenant_id")?.Value ?? string.Empty;
settings.UserId   = user?.FindFirst(ClaimTypes.NameIdentifier)?.Value ?? string.Empty;
settings.UserName = user?.Identity?.Name ?? string.Empty;

// The roles this user has: drives 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>();

// Every role and user in the system: populates the sharing pickers
settings.UserRoles = new List<string> { "Finance", "Sales", "Support", "Manager" };
settings.Users     = new List<dynamic>(); // e.g. { id = "u-42", text = "Jane Doe" }

Two properties look similar and are easy to mix up:

CurrentUserRole is the list of roles this user has. It's what access is checked against.
UserRoles (and Users) are every role and user in your app. They only fill the dropdowns when someone shares a report. They grant nothing.

The installed controller already reads ClaimTypes.Role claims into CurrentUserRole as a fallback, so if your login puts roles in the cookie you get this for free. Fill UserRoles and Users from your own user store. If you'd rather not do that in code, the users-and-roles setup lets you pick a different source (code, a SQL query or the portal).

One trap here. If UserId is empty and CurrentUserRole is empty, there's nothing to check access against, so the server-side access check returns early and everyone can see everything. That's fine on a dev box and wrong in production. The very first thing to check when "permissions don't work" is whether GetSettings() actually returns a user id.

Layer 2: permissions on reports and folders

Every report, folder and dashboard carries its own access fields. In the UI they show up as access badges:

Permission	By user	By role
Manage (edit)	`UserId`	`UserRoles`
View only	`ViewOnlyUserId`	`ViewOnlyUserRoles`
Delete	`DeleteOnlyUserId`	`DeleteOnlyUserRoles`
Tenant	`ClientId`

Each field is a comma-separated list. An empty field means "not restricted on that axis", which is why the manage badges read "Any User" / "Any Role" when they're blank. So a report with ViewOnlyUserRoles = "Finance" is readable by anyone in the Finance role, and a folder with UserRoles = "Support" can be managed by Support.

When an admin changes access from the Manage Access dialog, the front-end saves exactly those fields:

method: "/ReportApi/SaveReportAccess",
model: JSON.stringify({
  reportJson: JSON.stringify({
    Id: report.reportId,
    ClientId: access.clientId() || '',
    UserId: access.getAsList(access.users),
    ViewOnlyUserId: access.getAsList(access.viewOnlyUsers),
    DeleteOnlyUserId: access.getAsList(access.deleteOnlyUsers),
    UserRoles: access.getAsList(access.userRoles),
    ViewOnlyUserRoles: access.getAsList(access.viewOnlyUserRoles),
    DeleteOnlyUserRoles: access.getAsList(access.deleteOnlyUserRoles)
  })
})

Folders save the same fields through /ReportApi/SaveFolderData. Reports and folders also have a ShowAdminOnly flag ("Hide from reports unless Admin Mode is enabled") that keeps them out of the normal list. It's good for work-in-progress reports, or helper reports that only exist to be used as drill-downs. Treat it as tidiness, though, not security. Use the access fields for anything sensitive.

Sensible defaults for new reports

Most permission bugs are really defaults bugs. Someone creates a report, it's visible to the whole tenant, and nobody notices for a month. GetUsersAndRoles() in the API controller has a block that sets the starting permissions for every new report:

// Applied by default to any new report a user creates. Leave blank to allow access to all.
var newReportClientId      = "";        // comma separated client ids
var newReportEditUserId    = "";        // comma separated user ids with edit permission
var newReportViewUserId    = "";        // comma separated user ids with view permission
var newReportEditUserRoles = "Manager"; // comma separated roles with edit permission
var newReportViewUserRoles = "";        // comma separated roles with view permission

The front-end also adds the current user to the edit list of a new report, so the creator never locks themselves out of their own work. A reasonable SaaS default: tenant set from ClientId, the creator plus a "Manager" role can edit, and nobody else sees it until it's shared on purpose.

Where it's enforced

Hiding a report in the list is a UI nicety. It isn't security. The part that matters is on the server. Every report API call goes through CallReportApi, which builds the identity fields from GetSettings() and not from the request:

var settings = GetSettings();
if (!string.IsNullOrEmpty(settings.UserId) && settings.UserId != userId)
{
    throw new Exception("User context mismatch");
}

Then, for any call that names a report, folder or dashboard, it checks access with the reporting service before forwarding the call. That check uses the server-side user id, tenant and CurrentUserRole, and throws if access is denied:

if (!adminMode)
{
    if (dashboardId > 0) await ValidateAccess(userId, dashboardId: dashboardId);
    if (folderId > 0)    await ValidateAccess(userId, folderId: folderId);
    if (reportId > 0)    await ValidateAccess(userId, reportId: reportId);
}

So guessing a report id in the browser's dev tools doesn't get you that report.

Layer 3: admin mode and setup access are claims

The two "step outside the rules" permissions are claim types defined in ClaimsStore:

public const string AllowManageUsersAndRoles = "AllowManageUsersAndRoles";
public const string AllowSetupPageAccess     = "AllowSetupPageAccess";
public const string AllowAdminMode           = "AllowAdminMode";

AllowAdminMode lets a user switch the report builder into admin mode, where the banner reads "You can manage Reports/Dashboards for all users". GetSettings() turns the claim into a flag:

settings.CanUseAdminMode = ClaimsHelper.HasAnyRequiredClaim(
    User as ClaimsPrincipal, ClaimsStore.AllowAdminMode);

The admin-mode toggle only renders when that flag is true. More importantly, the server doesn't trust the toggle. CallReportApi drops an adminMode value from the request unless CanUseAdminMode is true, and a short list of account-level methods are refused outright for non-admins:

// The front end flag can be tampered with so check it here too
private static readonly string[] AdminOnlyApiMethods = new[]
{
    "/ReportApi/SaveReportHeader",
    "/ReportApi/SaveFolderData",
    "/ReportApi/DeleteFolder",
    "/ReportApi/SaveReportAccess"
};

if (!settings.CanUseAdminMode && AdminOnlyApiMethods.Contains(method, StringComparer.OrdinalIgnoreCase))
    return StatusCode(403, new { result = "You are not authorized to perform this action" });

In practice: ordinary users build and save reports within the permissions they've been given, while creating folders and changing access on existing reports are reserved for people with the claim.

AllowSetupPageAccess guards the /dotnetsetup screen, where you choose which tables and columns are exposed, rename fields, and set up joins. That's a schema-level permission, so it's on the controller rather than in the report data:

public class DotNetSetupController : Controller
{
    [CustomAuthorize(ClaimsStore.AllowSetupPageAccess)]
    public async Task<IActionResult> Index(string databaseApiKey = "") => View();

    [CustomAuthorize(ClaimsStore.AllowManageUsersAndRoles)]
    public async Task<IActionResult> UsersAndRoles(string databaseApiKey = "") => View();
}

CustomAuthorize checks user.HasClaim(c => c.Type == requiredClaim). It's the claim type that counts, not its value, so a claim of AllowSetupPageAccess = "false" still grants access. Don't add the claim at all for users who shouldn't have it. Unauthorized AJAX calls get a 403 JSON response, and page requests get a ForbidResult.

Issuing the claims at login

Map your own roles to these claims when you sign the user in, along these lines:

var claims = new List<Claim>
{
    new Claim(ClaimTypes.NameIdentifier, user.Id),
    new Claim(ClaimTypes.Name, user.DisplayName),
    new Claim("tenant_id", user.TenantId)
};
claims.AddRange(user.Roles.Select(r => new Claim(ClaimTypes.Role, r)));

if (user.Roles.Contains("ReportAdmin"))
    claims.Add(new Claim(ClaimsStore.AllowAdminMode, "true"));

if (user.IsPlatformStaff)
    claims.Add(new Claim(ClaimsStore.AllowSetupPageAccess, "true"));

If you use ASP.NET Core Identity, watch out for the security-stamp revalidation. It can rebuild the cookie principal from the user store and drop claims you added at login. The Program.cs in the main repo hooks OnValidatePrincipal and puts the custom claims back after the validator runs. If admin mode "randomly disappears after half an hour", that's the cause.

A role design that works for most SaaS apps

Everyone builds and saves their own reports. Set the new-report defaults so a fresh report is limited to its creator and their tenant.
Team roles (Finance, Sales, ...) get view-only or manage access to shared folders via ViewOnlyUserRoles / UserRoles.
ReportAdmin (a few people per tenant) gets AllowAdminMode to curate folders, fix other people's reports and manage access.
Your own staff get AllowSetupPageAccess. Customers almost never should: what's exposed in the schema is a platform-level decision.

Wrap-up

Keep identity on the server in GetSettings(), store permissions as data on each report and folder, and keep the powerful stuff behind claims the server checks on every call. The claims-driven GetSettings() and a demo with several roles are in dotnetreport/dotnetreport-multitenant-rls.

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.

Curating a reporting schema for self-service users: views, friendly names and what to hide

Razi Syed — Tue, 27 Oct 2026 15:58:06 +0000

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

Most self-service reporting projects don't fail in the report designer. They fail the first time a user opens the field list and sees tbl_ord_hdr, IsDeleted, RowVersion, LegacyStatusCd2 and four hundred tables in alphabetical order. They pick the wrong Status column, join orders to the wrong customer key, get a number that's off by the soft-deleted rows, and from then on "the reports are wrong" — even though every query ran exactly as written.

The fix isn't a better UI. It's treating the schema you expose to report builders as a product surface: curated, named for humans, pre-joined where joins are hard, and with the dangerous parts simply absent. This article is the checklist I use, with the setup screen of Dotnet Report (which I work on — disclosure) as the concrete example. The principles apply whatever tool you use.

The rule: curate it like a public API

Your database schema is shaped for your application: normalized, full of plumbing columns, named by whoever wrote the migration in 2017. A reporting schema should be shaped for the question "what happened to the business?" Those are different consumers, and you'd never ship your internal tables as a public API. Same idea here.

Concretely that means four decisions per table: does it go in at all, what is it called, how does it join, and what's hidden.

1. Prefer views over raw tables

My default is that end users report on views, not base tables. A view lets you fix the problems once, in SQL, under version control, instead of hoping every user remembers them:

CREATE VIEW reporting.Orders AS
SELECT
    o.OrderId,
    o.OrderDate,
    c.CompanyName      AS Customer,
    r.RegionName       AS Region,
    o.Subtotal,
    o.TaxAmount,
    o.Subtotal + o.TaxAmount AS OrderTotal,
    CASE o.StatusCode
        WHEN 1 THEN 'Open'
        WHEN 2 THEN 'Shipped'
        WHEN 3 THEN 'Cancelled'
    END                AS Status,
    o.TenantId
FROM dbo.tbl_ord_hdr o
JOIN dbo.Customers c ON c.CustomerId = o.CustomerId
LEFT JOIN dbo.Regions r ON r.RegionId = c.RegionId
WHERE o.IsDeleted = 0;

That one view removes soft-deleted rows, turns a magic status code into words, pre-computes the total everybody would otherwise calculate slightly differently, and flattens the two joins that users get wrong most often. Put views like this in their own schema (reporting. here) and ship them in your normal migrations, so they're reviewed like any other code.

In Dotnet Report's setup screen (/dotnetsetup), the Database Tables tab loads both tables and views from your connection — views are marked (view) — and you tick the ones to expose. The ones you don't tick simply don't exist as far as report builders are concerned. Start with fewer than you think: ten well-shaped views beat two hundred raw tables.

When raw tables are fine: small, already-clean lookup tables (Products, Regions) where a view would just be SELECT *. Don't add ceremony where there's no problem to fix.

2. Name everything for the reader

Every table and column you expose gets a Display Name. tbl_ord_hdr becomes Orders, cust_nm becomes Customer Name. In the setup screen the database name stays visible on hover ("DB field is …"), so developers can still trace a field back to the source while users only ever see the friendly one.

Two other per-column settings are worth five minutes each:

Field Type. Beyond the obvious types, you can mark a numeric column as Money or Percentage, and a date column as Date Only or Time Only. The designer uses the type to decide what makes sense for a column — numeric types like Money can be summed and charted on a value axis, a Percentage column is formatted as a percentage by default — so it's the difference between 0.1834 and 18.34%.
Categories. Group tables into a handful of categories (Sales, Inventory, Finance) via Manage Categories, so the table list reads like a menu instead of a dump.

A naming convention helps more than any individual name: singular vs plural, "Date" suffix on every date, no abbreviations. Write it down once and apply it everywhere.

3. Get joins right once, centrally

Self-service tools build SQL dynamically, so they need to know how tables relate. The Relations tab is where that lives, and it gives you three ways to fill it:

Import from Database reads the foreign keys actually defined in your database.
Auto Add Joins guesses joins from column names ending in Id and shows each candidate with a status (New, Already exists, and so on) before adding it.
Add new Join for anything else, with a join type of INNER, LEFT, RIGHT or CROSS, plus extra AND conditions for composite keys.

Treat the guesses as a draft. The classic mistake is an INNER join from orders to an optional relationship (a sales rep, a promo code) that silently drops every order without one. If a relationship is optional, make it LEFT. And if a join path is genuinely ambiguous — orders have both a billing and a shipping customer — don't make users choose: pre-join it in a view with two clearly named columns.

Lookups instead of ids. Users shouldn't filter on RegionId = 7. Mark the column as a Foreign Key and point it at the lookup table: the Foreign Key Field is the id, the Foreign Value Field is what users see in the designer. Tick Only for Filter? when you want the friendly dropdown in filters, but the column in the report itself should keep its stored value without joining the lookup table in. You can also set a parent for a foreign key to get cascading filters (pick a country, then only its regions).

4. Decide what to hide — and what to never include

There are two different things people mean by "hide", and mixing them up is how data leaks.

Presentation hiding. Do Not Display removes a column (or a whole table) from what report builders can pick, while keeping it available for joins. Use it for keys and plumbing columns that a join needs but no human wants to see: CustomerId, RowVersion, TenantId.

Security exclusion. Password hashes, tokens, raw personal data you don't need for reporting, internal notes — these shouldn't be in the reporting schema at all. Leave them out of your views. A column that isn't selected can't leak through a bug, a misconfiguration or a creative custom SQL field later on. The view is your allowlist.

Between those two sits role-based access. Each table and column has Manage Role Access, where you tick which roles may use it (the dialog notes that if no roles are set, all users have access). The roles come from what you pass as CurrentUserRole in GetSettings():

settings.UserId = User.Identity.Name;
settings.CurrentUserRole = User.Claims
    .Where(c => c.Type == ClaimTypes.Role)
    .Select(c => c.Value)
    .ToList();

So Salary can exist on the Employees view for HR and be invisible to everyone else. I'll cover roles, folders and sharing properly in a follow-up. And tenant isolation is a separate layer again — ClientId and DataFilters, covered in Multi-tenant reporting in ASP.NET Core: row-level security your users can't bypass. Curation decides what users can see; row-level security decides whose rows.

5. Custom tables: views you don't have to deploy

Sometimes you need a reporting shape but can't (or don't want to) add a database view — a customer's database you don't own, or a quick experiment. The Custom Tables tab lets you define a table as a SQL SELECT; Dotnet Report reads the result's columns and you then name and configure them like any other table.

Custom table SQL is checked before it's accepted: GetSchemaFromSql rejects anything that isn't a single read-only statement — it must start with SELECT or WITH, and multiple statements or sp_/xp_ procedures are refused. That's a sensible guardrail, not a reason to put complex logic there. My rule of thumb: if the shape is permanent and you own the database, make it a real view in your migrations; use custom tables for the cases where you can't.

6. Guardrails for expensive columns

Curation is also about keeping users from writing the one query that scans five years of events. Two per-column options help:

Require Filter if Column is selected / Require Filter if Table is selected — the report can't run until the user picks a value, e.g. a tenant, a store, or a date.
Restrict Filter Date Range — cap a date filter at a number of days, months or years, so nobody asks for "all time" on your largest table.

These are cheap to set and save you from explaining to someone why their report took four minutes.

7. Lock the setup screen itself

Everything above is configuration that changes what every user sees, so the setup page is an admin tool, not a user feature. The page itself warns you not to expose it to end users. In the source, the controller is gated by a claim:

public class DotNetSetupController : Controller
{
    [CustomAuthorize(ClaimsStore.AllowSetupPageAccess)]
    public async Task<IActionResult> Index(string databaseApiKey = "")
    {
        return View();
    }
}

and admin mode in the report designer is gated separately in GetSettings():

settings.CanUseAdminMode = ClaimsHelper.HasAnyRequiredClaim(
    User as ClaimsPrincipal, ClaimsStore.AllowAdminMode);

Give AllowSetupPageAccess to the developers or data owners who curate the schema, and nobody else.

The checklist

Before you hand self-service reporting to users, walk each exposed table through this:

Is it a view? If the raw table needs any fix-ups (soft deletes, codes, computed totals, awkward joins), yes.
Is every name human? Table, columns, categories, consistent convention.
Are the joins reviewed? Imported or guessed joins checked, optional relationships LEFT, ambiguous paths pre-joined.
Are ids shown as names? Foreign-key lookups set up for every id users might filter on.
Is anything sensitive in the view at all? If so, remove it from the view rather than hiding it.
Who should see it? Role access on sensitive tables and columns.
Can it hurt the database? Required filters and date-range caps on the big ones.

None of this is glamorous, but it's where self-service reporting succeeds or fails. Users trust numbers from a schema that makes sense to them, and they stop asking you to "just pull a quick report."

If you're starting from zero, set up the report builder first with Add self-service ad hoc reporting to an ASP.NET Core app, then come back to this list before you invite your first users.

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.

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.

DEV Community: Razi Syed

Role-based access to reports and folders in ASP.NET Core: users, roles and admin claims

Three separate layers

Layer 1: identity in GetSettings()

Layer 2: permissions on reports and folders

Sensible defaults for new reports

Where it's enforced

Layer 3: admin mode and setup access are claims

Issuing the claims at login

A role design that works for most SaaS apps

Wrap-up

Curating a reporting schema for self-service users: views, friendly names and what to hide

The rule: curate it like a public API

1. Prefer views over raw tables

2. Name everything for the reader

3. Get joins right once, centrally

4. Decide what to hide — and what to never include

5. Custom tables: views you don't have to deploy

6. Guardrails for expensive columns

7. Lock the setup screen itself

The checklist

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

The design in one paragraph

1. Starting the job

2. Cron + time zones, evaluated against last run

3. Rendering PDF and Excel

4. Security when nobody is logged in

5. Email

Hosting: the two rules

Wrap-up

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

Why "just add the WHERE clause" stops working

One method, every request

Drive it from claims, never from input

What about exports and scheduled reports?

Cases you'll hit in practice

Testing it

Takeaways

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

What "self-service" actually means here

Step 1 — install the package

Step 2 — configuration

Step 3 — register the services it depends on

Step 4 — expose your schema

Step 5 — hand it to users

The next two things you'll need

When you shouldn't do this

Wrap-up

Layer 1: identity in `GetSettings()`