Groups
Named, with a description, and required on every user.
Access · Groups and users
Local teams publish.
Just not everywhere.
The reason head office will not give a branch manager the login is that they might publish to all forty branches. Groups are how that stops being a reason.
Plans, prices and trials are set by your ScreenQube partner.
Where it ends up
You work in a browser.
They see the wall.
The screen above is what you publish. This is where it ends up.
How it is made
What is actually behind it.
Named against the product's own modules rather than invented for a marketing page.
-
A user belongs to a group
Group membership is required when a user is created.
-
A group carries permissions
A matrix per resource, not a single role name.
-
And facility access
Which sites that group can touch at all.
-
Impersonate, on the partner side
A partner can enter a client's console to support it.
What you get
Six things it does today.
A permission matrix
Per resource, rather than three fixed role names.
Facility access
So a branch publishes to its branch.
Impersonate
A partner can enter a client's console — at partner and user level.
Every change audited
Group and user changes are in the audit log like anything else.
No single sign-on
Stated plainly. Access is managed in the console.
Who runs this
The industries that ask for it.
Nearby
Solutions that go with it.
Questions
The things people actually ask.
Is there SSO?
No. Users and groups are managed in the console. If SSO is a requirement, this is the wrong product today.
Can a branch publish only to its own screens?
Yes. Facility access is part of what a group decides.
Is Groups optional when creating a user?
No — QA records it as mandatory. Every user belongs to a group.
Can our partner see our content?
A partner can impersonate an organisation's console to support it. That is a real capability and worth knowing about before you assume otherwise.