Getting Started With Groups And Roles

GreenSparks is used by several kinds of people working around the same events, devices, reports, and operational workflows. Groups and roles help keep that work organized.

The short version is:

Groups decide which data you can see.
Roles decide which actions you can take.
Your device type may limit whether a workflow is practical on phone, tablet, or desktop.

If a feature is missing, disabled, or partly available, it is usually because of one of those three rules.

1. GreenSparks Features And Functions

GreenSparks helps teams understand temporary and venue-based energy activity. The main product areas are:

Home: a starting point for the data and workflows available to you.
Devices: monitored equipment, organized through global Categories and Products.
Events: event structures, including Zones and Virtual Devices.
Venues: locations and venue structures.
Reports: reusable views of Events, Devices, and related data.
Maps: visual event, venue, and zone context.
Operations: assigning physical Devices to Virtual Devices and managing field state such as load-in, load-out, power up, power down, and power/network connected status.
Engineering: technical setup, JSON/specification work, and device engineering tests.
Groups and People: administration of Groups, users, memberships, and roles.
Agents: GreenSparks-owned data collection and runtime infrastructure.

Not every user sees every feature. GreenSparks should only show the tools that are useful and appropriate for your membership and role.

2. Groups

A Group is usually a company, organization, or operational team.

Common examples include:

Event presenters, who own Events and may also own Devices.
Equipment providers, who own Devices and supply monitored equipment.
Service providers, such as contractors who work as engineers, operators, analysts, or support teams.

Groups own parts of the GreenSparks data model. For example:

Events can be owned by Groups.
Devices can be owned by Groups.
Zones and Virtual Devices inherit ownership from their Event.
Categories, Products, and Venues are global references in the current model.

If you are not a member of the Group that owns an Event or Device, that Event or Device should not appear in your normal app experience.

3. User Types

Your role is assigned within a Group, except for System User, which is global. The same person can be a Basic User in one Group and an Admin, Operator, or Engineer in another Group.

User type	Scope	High-level capabilities
Basic User	Group	View and work with visible Events, Devices, Venues, Categories, Products, and Reports. Create Events, Devices, and Reports owned by Groups where they are a member.
Admin	Group	Basic User functions, plus Group membership management, invitations, Group-scoped roles, and user review for Groups they administer. Admin does not include Operator or Engineer powers.
Operator	Group	Basic User functions, plus Operations work such as Device-to-Virtual-Device assignment, load-in, load-out, power up, power down, and power/network state. Operator does not include Admin or Engineer powers.
Engineer	Group	Basic User functions, plus Engineering surfaces for technical setup, JSON/spec work, validation, and device engineering tasks within visible scope. Engineer does not include Admin or Operator powers.
System User	Global	GreenSparks-wide access across all Groups, users, roles, owned entities, Agents, and administrative functions.

All Group roles share one baseline: an active member can create ordinary content for that Group, including Events, Devices, and Reports. Specialized roles add narrow capabilities. If one person needs multiple specialties, they should be given multiple roles rather than relying on role overlap.

When you create an Event or Device, GreenSparks assigns an owner Group. If only one owner is possible, the app states that owner. If more than one owner is possible, you choose the owner before saving.

Reports are authored by a person, but visibility follows the Groups represented in the selected Events or Devices. If a saved Report includes content owned by Groups A and B, members of both Groups can see that saved Report. If ownership cannot be inferred from the selected entities, the Share tab asks you to choose a fallback owner Group.

4. What You Can See

GreenSparks should filter owned data before it reaches the user experience.

For regular users:

You see Events and Devices owned by Groups where you have active membership.
You see Zones and Virtual Devices that belong to visible Events.
You see Reports that are visible to one of your Groups.
You see global reference data such as Venues, Categories, and Products.

For System Users:

You can see all Groups.
You can see all owned Events and Devices.
You can see all user and role management surfaces.
You can use System-only surfaces such as Agents.

5. Why A Feature May Be Missing Or Disabled

GreenSparks should make access rules understandable. When possible, the app should explain why a feature is not available.

Common reasons include:

Hidden because of role: Engineering is not shown to users who are not Engineers or System Users.
Hidden because of Group scope: Events and Devices owned by other Groups do not appear.
Disabled because the action is protected: a Group Admin may not be allowed to remove the last active Admin from a Group.
Read-only because context matters: a Group Admin may see that a user belongs to another Group, but cannot edit that other membership.
Limited because of device type: a phone may show status and emergency controls while leaving dense Engineering work for desktop.

Good UX indicators include:

owner labels on Events, Devices, and Reports
role labels in user and Group membership tables
disabled controls with short explanations
empty-state messages when no visible records are in scope
concise notices when a phone or tablet cannot safely support a dense workflow

If a rule is difficult to explain in one or two sentences, it may need product review before it becomes a permanent workflow.

6. Mobile, Tablet, And Desktop Limits

Mobile access is not just a permissions issue. Some workflows are too dense or precise to be comfortable on a phone.

GreenSparks should treat device class as a suitability rule:

Device class	Best suited for	Likely limits
Phone	Checking status, reading reports, quick operational updates, emergency reassignment when the UI supports it	Dense tables, complex tree editing, JSON/spec editing, and multi-panel review
Tablet	Most field operations, maps, load-in/load-out, assignment workflows, report review	Very dense engineering work may still be better on desktop
Desktop	Full reporting, administration, Groups and People management, Engineering, diagnostics, and detailed editing	Few limits beyond role and Group permission

Platform details such as iOS, Android, macOS, Windows, and Linux usually matter less than screen size and input style. Platform only becomes important when a feature depends on device capability, such as file upload, drag-and-drop, or local agent tooling.

7. What To Read Next

Choose the next guide based on your role or task.

If you are…	Read next
New to GreenSparks	Getting Started
A Basic User creating reports	Reports Guide and Sharing Data Guide
A Group Admin	Admin Guide and People/Profile help
An Operator	Operator Handbook, Events help, Devices help, and Maps help
An Engineer	Engineering Guide and Devices help
A System User	Admin Guide, Engineering Guide, Agents help, and diagnostics documentation
An event presenter	Working With Events And Venues, Reports Guide, and Sharing Data Guide
An equipment provider	Working With Devices, Reports Guide, and Operator Handbook
A service provider	The guide for the role you are performing: Admin, Operator, Engineer, or reporting/data analysis

8. What Should Feel Clear

After reading this guide, you should be able to answer:

Which Group owns the Event, Device, or Report I am looking at?
Which role do I have in that Group?
Is this feature hidden because of my role, my Group membership, or my device type?
If something is disabled, what would need to change for it to become available?

If the app does not answer those questions clearly, the documentation and the interface should be improved together.