Basics: sites, plants and who sees what

In OPEREX the diary is not one big shared box: three levels structure it, and access is built on the same levels. This page explains those three — what a site is, what a plant is, and who sees what. Once the structure makes sense, the concrete steps are in the articles linked at the end.

The three levels

Organization (your account)

The company using OPEREX. This is the outermost frame: roles, the permission matrix, the language and billing live here. One organization can hold one or many sites.

Site

A physical location (a works, a branch). It has its own plants, its own worker roster, its own diaries, its own shift schedule and its own PDF dispatch. There is one site by default — add more only if you really run geographically separate locations.

Plant

A unit inside a site (e.g. Phosgene, Reactor, Tank farm). Every plant gets its own diary elements, its own live and archive log and its own writer permissions; you switch between them in the diary’s top bar.

A diary is always the diary of one plant, one shift. The plant belongs to a site, the site to the organization — so every record has an unambiguous place, and reports can aggregate along that same tree.

Two kinds of plant diary

A plant can be a “Unit log” (the daily technology log) or a “Shift supervisor log” (the shift’s summary log). The difference is not just naming: board and outside operators may only write a unit log; the shift supervisor log is for the shift leader (and plant-spanning roles). This limit is enforced in code — no permission toggle turns it off.

Who can see which site

Not everyone sees a site — deliberately: site access is fail-closed, meaning no access until you grant it. Access has two layers, and you have to set both:

The Site access card on the Users tab. A colleague with a company-wide role has no checkboxes — they see everything by role.

1. The role’s scope (Permissions tab → “Site access” column): “All sites” = company-wide, the role sees every site; “Selected sites” = site-bound, the role sees only the assigned sites.
2. The specific sites (Users tab → “Site access” card): here you tick, per user, which sites they can reach. For a new colleague you can do it right at invitation time (“Which sites they can access”).

A user with no site ticked cannot get in anywhere

“A site-bound role sees ONLY the checked sites — if a user has none checked, they can’t access anything (this is the safe default).” That is not a bug, it is the model. If a colleague “sees nothing” after signing in, check this first.

Company-wide by default are only three roles: System administrator, Production manager and the OpEx team. Every other role — including the Site manager — is site-bound, so you must tick the sites they may reach. (The Site manager is bound precisely because the name points at one site.) This starting point is not fixed: the role’s scope is adjustable in the first layer.

Who may write a plant’s diary

Plant access is a separate layer, and it works the other way around: the default is not denial but openness. A plant stays unrestricted until you designate writers for it.

On the Plants tab, inside the plant’s card. The header tells you whether the plant is currently restricted, or “not restricted — anyone can write”.

• While you designate nobody, the plant is not restricted: anyone with the role permission can write.
• As soon as you designate at least one writer, the plant becomes restricted: only those (plus plant-spanning roles — managers, admin) can write into it.
• Only plant-bound roles can be designated: Shift leader, Board operator, Outside operator. The other roles are plant-spanning and have no checkbox here.

The Roster is NOT access

“This is not the Roster: here you pick sign-in users, not the attendance list.” The Roster’s plant selector controls which plant’s headcount list a NAME appears in — those are worker names, not OPEREX accounts. The two are easy to mix up, but they are different things.

Many roles — what each is for

The system knows 11 built-in roles, and you can create custom roles on top of them (starting from an existing role’s permissions). The role decides what you may do; the two layers above decide where.

Role	Typically	Default site scope
System administrator	full access; their permissions cannot be restricted	all sites
Production manager	company-level production oversight	all sites
OpEx team	improvement, analysis, reports	all sites
Site manager	running one site	selected site(s)
Plant group manager	several plants together	selected site(s)
Data supervisor	master data, diary structure, roster	selected site(s)
Shift leader	writing the shift diary, the summary	selected site(s)
Board operator	writing the unit log from the control room	selected site(s)
Outside operator	writing the unit log from the field	selected site(s)
Maintenance manager	directing maintenance work	selected site(s)
Maintenance engineer	doing maintenance work	selected site(s)

The individual permissions (log an event, issue a task, export a report…) are toggled per role in the Permissions matrix — the rows above describe the typical use and the site-scope starting point, not a closed list.

Worth knowing

• With one site you see none of this. The site switcher, the site selectors and the site-access card appear only with multiple sites — a single-site account stays exactly as simple as before.
• The site is a global context. Switching site in the header moves not only the diary but also tasks, events, maintenance and the reports.
• Each site may use its own shift schedule — and that is not only convenience: it decides when the diary opens and closes and when the PDF goes out. See A separate shift schedule per site.

Related

Create a site and grant accessThe concrete steps: a new site, then who may reach it.

Manage sites and plantsAdding, renaming and ordering plants.

Custom roles and the permission matrixRole permissions — the 'what you may do' layer.

A separate shift schedule per sitePer-site shifts — and what depends on them.