When a SCADA platform emails a report to a fixed list of addresses, someone has to maintain that list by hand: adding new staff, removing people who left, and fielding requests to change who gets what. A report subscription flips that model by letting each user manage their own delivery. This guide explains the self-service subscription model, how opt-in and cadence choices work per user, and how a subscription is scoped so a person only receives reports covering data they are allowed to see.
Report Subscription in one line: A report subscription lets an individual user subscribe or unsubscribe themselves to a specific scheduled report and choose their own delivery cadence and format, instead of an administrator hand-maintaining a shared email distribution list. Each subscriber controls their own membership, and the platform scopes what they can receive to the sites and data their permissions allow.
In the older distribution model, a report is defined once and pointed at a static list of recipients. That list is a maintenance burden: it drifts out of date the moment someone changes teams, and every change is a ticket to whoever administers the platform. It is also opaque to the recipients themselves, who cannot tell what they are signed up for or quietly step off a report they no longer need. A report subscription replaces the central list with a self-service one.
Under a subscription model the report still runs on its schedule, but membership is owned by the users. A person browses the available reports, subscribes to the ones relevant to their role, and unsubscribes from anything that is noise to them. The administrator no longer curates individual inboxes; they publish which reports exist and who is eligible, and the roster of actual recipients assembles itself from the choices people make. Onboarding a new hire becomes a matter of that hire subscribing, not an admin editing a dozen distribution lists.
Because each subscription is a per-user record, the platform can also expose useful controls that a shared list cannot. A user might subscribe to the daily production report but only want it on weekdays, or take the shift summary as a PDF while a colleague takes the same report as a raw export. Those preferences live on the individual subscription, so one report definition serves many people with different needs without cloning the report for each variation.
The most visible part of a subscription is the delivery choice. A subscriber typically picks how often they receive the report where the schedule allows options - every run, once a day as a digest, or weekly - and which format they want, such as a rendered PDF for reading or a data file for analysis. These preferences attach to the subscription, so changing them affects only that person and never the report itself or anyone else subscribed to it.
Recipient management becomes an emergent property of the system rather than a manual task. At any moment the set of people receiving a report is simply the set of active subscriptions to it, which stays current because people manage their own. This removes the classic failure of stale lists, where a report keeps being sent to an address that no longer belongs to anyone or stops reaching a team that quietly grew. It also gives each user a single place to review and prune everything they are signed up for.
Administrators keep an oversight role even in a self-service model. They decide which reports are published for subscription, may pre-subscribe certain roles so critical reports are never missed, and can audit who is receiving what. The difference is that the day-to-day churn of who is on which list is handled by the users themselves, so the administrator manages policy and eligibility rather than individual email addresses.
On a multi-user hosted SCADA, a report often summarizes data from many sites, and not every user is entitled to every site. A subscription model has to respect that. When a user subscribes to a report, the platform scopes the content they receive to what their permissions already allow, so a technician responsible for one field does not receive volumes from fields they cannot access. The same report definition can therefore be safely offered to a wide audience, because each subscriber's copy is filtered to their authorized scope.
This scoping is what makes self-service safe on a shared platform. Without it, letting anyone subscribe to any report would be a data-exposure problem, since a report is only as private as its narrowest recipient. By binding the subscription to the subscriber's existing access rights, the platform ensures that opting in never grants a person visibility they did not already have. If a user's permissions are later reduced, the reports they still receive shrink to match automatically.
For field operations this combination is practical. A company running many remote sites under one account can publish a standard set of reports once, and each area lead, operator, and manager subscribes to the ones they need, receiving only their own sites at the cadence they prefer. Access control, subscription management, and report generation stay consistent with each other, so onboarding, offboarding, and role changes flow through to reporting without a separate list to keep in sync.
A distribution list is a static set of recipients that an administrator edits by hand, so it drifts out of date and every change is a request to IT. A report subscription is owned by the individual user, who subscribes or unsubscribes themselves and sets their own cadence and format. The list of recipients then becomes the set of active subscriptions, which stays current on its own.
Yes, within whatever the report's schedule offers. Because preferences live on each user's subscription rather than on the report, one person can take a report as a daily digest while another takes every run, and one can receive a PDF while another receives a raw data file. Changing a preference affects only that subscriber and never the report or other recipients.
No, when the platform scopes subscriptions to existing permissions. Each subscriber's copy is filtered to the sites and data their access rights already allow, so opting in never grants visibility they did not have. If their permissions are later reduced, the content they receive shrinks to match, which is what makes broad self-service safe on a shared, multi-user platform.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.