DataPallas Server is used by several people at once, so it needs to know who is at the keyboard and what that person may do. This page covers the account the server ships with, how to create accounts for your colleagues, what each of the four roles can do, how groups decide which databases, reports and dashboards people can reach, and how to let people sign in with the account they already have at work.

Table of Contents

• Start Here — the burst / burst Account
• Where Users Are Managed
• The Four Roles
• Creating a User
• Everyday Tasks
• Groups — Who Can Reach What
• Sharing Dashboards With People Who Only Look
• Who Is Allowed To Do What
• Sign In With Your Company Accounts
• Troubleshooting

Start Here — the burst / burst Account

The first time you start DataPallas Server it creates one administrator account, burst with the password burst, so you can start it and be up and running straight away. Until you change that password the login page says so:

Anyone who can open the login page can read those credentials and sign in as an administrator, so change them in the first five minutes:

1. Sign in as burst / burst.
2. Open your own name in the top right of the screen, then Users.
3. Either Reset Password on the burst row and give it a real password, or — better — create a user with your own name and the ADMIN role, sign in as yourself, and delete burst.

The notice disappears on its own the moment you do.

Where Users Are Managed

Everything about people lives in one place: your own name in the top right → Users. It is not in the Configuration menu.

Under your name you also see the role you currently hold, a quick check of what you are signed in as when a screen seems to be missing.

• You only see the Users entry if you are an ADMIN. For everybody else it is simply not there — nothing is greyed out and nothing gives an error.
• On DataPallas Desktop it never appears, because there are no users to manage.

The Users screen has three tabs: Users, Groups and License, where you enter, check and renew your license key.

The Four Roles

Every user has exactly one role. ADMIN, REPORT_AUTHOR and JOB_OPERATOR are a ladder: each one can do everything the one below it can do, plus more. DASHBOARD_VIEWER stands apart: it only opens the dashboards shared with its groups — which a JOB_OPERATOR does not do, because operators do not use the AI Hub.

A few things worth knowing:

• A new DASHBOARD_VIEWER sees nothing until an administrator shares at least one dashboard with one of their groups.
• You cannot change your own role, and you cannot disable or delete yourself. Those controls are switched off on your own row, so the last administrator cannot lock everyone out by accident.
• Your license may cap how many users you can create. If it does, creating one more is refused with a clear message. Contact us to add seats.

Creating a User

1. Go to your name (top right) → Users → Users and click New User.
2. Fill in a username, a password, optionally an email address, and pick a role. A one-line description of the role is shown under the picker. The picker starts on JOB_OPERATOR — the safest everyday choice, someone who can run jobs and read what they produced and nothing more — so nobody becomes a builder or an administrator by accident. Change it to REPORT_AUTHOR for somebody who builds, or DASHBOARD_VIEWER for somebody who only looks (the example below has been changed to REPORT_AUTHOR for Anna, who builds reports).
3. Optionally tick the groups they belong to (see Groups). You can do this later.
4. Click Create. The new person can sign in immediately.

If the name is already taken you are told straight away and nothing is created.

Passwords are set by an administrator — there is no "change my own password" page. Somebody who forgot theirs, or wants one only they know, asks an ADMIN to Reset Password on their row.

Everyday Tasks

All of these are on the person's row in the Users tab:

• Edit — change their groups, and set their time zone and locale. Leave those two empty to use the default for everyone (the screen calls it the tenant's), which is the server's own unless it has been set otherwise. The time zone is what "today" means in a dashboard that filters on today's date, so a colleague in Auckland and one in Los Angeles each see their own day.
• Role — the picker on their row.
• Reset Password — set a new password; you do not need the old one.
• Disable / Enable — stop someone signing in, or let them back in with the same role and groups. Use it for long leave, or to close an account quickly while you look into something.
• Delete — removes the account for good. Use Disable if there is any chance you will want them back.

Once the list grows past a page, a search box appears that matches name, email address and role.

The Edit screen also shows what the person's groups add up to — their effective limits, the reports they can see and, for a dashboard viewer, the dashboard they open on:

Groups — Who Can Reach What

A role says what kind of work somebody does. A group says which databases, reports and dashboards they can reach. Create groups in Users → Groups → New Group, then put people in them on the Edit screen of each user.

For each group you can:

• Limit the members — tick Limit the members of this group, then choose All connections or Only these database connections, and whether members may write scripts (Groovy, Jasper templates, script-mode widgets) — see What May write scripts Does.
• Choose the reports the group can see. Tick nothing and the group does not limit reports; tick some and members are limited to the reports their groups tick.
• Share dashboards and pick the one the group lands on — see the next section.

How the rules combine:

• A person gets everything their limiting groups allow, added up. Putting somebody into a second group with more connections or more reports ticked gives them more.
• A group that sets nothing adds nothing. A group without Limit the members does not lift the connection limits of the person's other groups, and a group that ticks no reports does not give back the reports the others leave out. Someone in Sales managers (only the Sales database) and in an All staff group that limits nothing can still use only the Sales database.
• People in no limiting group are not limited, and administrators never are. Nothing changes for existing users until you create a group that sets limits.
• Limits apply to everyone who is not an ADMIN — authors, operators and viewers alike. A report whose database connection a person may not use is not listed to them and does not run for them.
• Connection limits only hold when May write scripts is off, because a person who can write scripts can reach any database through a script. The screen warns you when you choose Only these and leave scripts on.
• A new group limits nobody. Limit the members starts unticked, and once ticked the choices start on All connections with scripts allowed, so nothing changes for anybody until you decide it should. Choosing Only these and ticking no connection gives the members no database connections at all, and the screen warns you when you do.
• A group cannot be deleted while it still has members — move them first, so nobody's access changes by surprise.

What May write scripts Does

DataPallas reports can contain code: a Groovy script that fetches or reshapes data, a Jasper template, a script-mode widget on a dashboard. Whoever saves that code decides what runs on your server, so by default every member of every group may. Untick May write scripts to give a group the analyst's version of REPORT_AUTHOR: people who build with SQL and the visual tools, but do not write code.

It stops people writing code, not running reports. With it off, members can still:

• build SQL reports, charts, pivot tables, tabulators, cubes and dashboards — their definitions are checked when saved, and one that tries to read files, reach the network or run commands is refused;
• save FreeMarker, HTML and Word templates;
• run any report, including one that already has scripts in it.

They can no longer:

• save a report's Groovy datasource script or additional-transformation script;
• save a Jasper template (.jrxml);
• run an ad-hoc script in the editor;
• save or publish a dashboard that has a script-mode widget;
• write, copy or move .groovy and .jrxml files, or anything in a scripts folder, through the file explorer.

It is also what makes Only these database connections a real limit — see above. Administrators are never limited by it, and for operators and viewers it changes little, because they do not author anything anyway.

Each group also shows a short Name in SQL under its name. It does not change when you rename the group, and it is what a dashboard's access filter uses to show different people different rows — for example only their own customers.

Sharing Dashboards With People Who Only Look

1. Publish the dashboard (see Dashboards).
2. In Users → Groups, create a group (say Sales managers) and tick the dashboard under Dashboards this group can see. Pick one as the Default — it is the one people land on. If you pick none, they land on the first dashboard in their list, in name order.
3. Create each person with the DASHBOARD_VIEWER role and tick that group.
4. Give them the address of the AI Hub (the Explore Data & Build Dashboards app) and tell them to sign in there with the same account. If they sign in with a "Sign in with …" button instead, they do that on the main DataPallas login page first — see The AI Hub Comes Along.

This is what they see — no menus, only their dashboards, with the picker next to their name to switch between them:

A viewer opens only the dashboards their groups were given and can switch between them. A dashboard that has been shared opens fully for them, even if the group's connection limits would otherwise hide its data — you ticked it by hand, so that is your decision. If a viewer signs in to the main DataPallas screens instead, they get this instead of the application:

Who Is Allowed To Do What

Screens a person may not use are not hidden behind a warning — they are simply not in their menu.

Sign In With Your Company Accounts

Out of the box DataPallas keeps its own small list of users, and for many installations that is the end of the story. If your organization already has a directory or single sign-on, you can point DataPallas at it so people sign in with the account they already have, new joiners need no second one, and leavers lose access here when they lose it everywhere else.

This is configuration, not a plugin: add a few lines to one file and restart.

<your DataPallas install>/config/application.properties

With a single sign-on provider (Microsoft Entra ID, Okta, Google and the others below), a "Sign in with …" button then appears on the login page, under the ordinary username and password form. With Active Directory or LDAP there is no button: people type their directory username and password into the ordinary form.

Four Rules Worth Knowing First

1. Your local accounts keep working. DataPallas checks its own list first, then your directory, so an unreachable or misconfigured directory never locks you out. Keep one local administrator.
2. Your directory says who someone is; DataPallas says what they may do. The first time somebody signs in, DataPallas creates a record for them to hold their role and groups. It has no password of its own.
3. Group membership is re-checked at every sign-in. While someone is in one of your mapped groups, their role here follows it: move them from your admins group to your authors group and they are a REPORT_AUTHOR the next time they sign in. If they are in several mapped groups, the strongest role wins. Taking someone out of every mapped group does not lower their role — they keep the one they had, so change it on the Users screen, or disable them.
4. New people arrive as JOB_OPERATOR unless one of your directory groups maps to another role. Building and administering are granted deliberately. People who sign in this way are also placed in DataPallas groups by an administrator on the Edit screen, as for any other user.

Microsoft — Entra ID (Azure AD) and Active Directory

Microsoft Entra ID (the cloud one). In the Azure portal, register DataPallas as an application, add the redirect URL https://<your-datapallas-host>:9090/login/oauth2/code/entra, and under Token configuration add a groups claim. Then:

spring.security.oauth2.client.registration.entra.client-id=<application (client) ID>
spring.security.oauth2.client.registration.entra.client-secret=<client secret>
spring.security.oauth2.client.registration.entra.client-name=Microsoft
spring.security.oauth2.client.registration.entra.scope=openid,profile,email
spring.security.oauth2.client.registration.entra.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.entra.redirect-uri={baseUrl}/login/oauth2/code/{registrationId}
spring.security.oauth2.client.provider.entra.issuer-uri=https://login.microsoftonline.com/<tenant-id>/v2.0
 
# which of your groups gets which DataPallas role
datapallas.oidc.group-role-map.DataPallas-Admins=ADMIN
datapallas.oidc.group-role-map.DataPallas-Authors=REPORT_AUTHOR
datapallas.oidc.group-role-map.DataPallas-Viewers=DASHBOARD_VIEWER
datapallas.oidc.default-role=JOB_OPERATOR

Entra normally sends group IDs (long GUIDs) rather than names: map the GUIDs, or use Entra App roles, which arrive by name.

Active Directory (on-premises). People sign in with their ordinary domain account; there is nothing to register:

datapallas.ldap.enabled=true
datapallas.ldap.url=ldaps://dc01.corp.local:636
datapallas.ldap.domain=corp.local
datapallas.ldap.base-dn=dc=corp,dc=local
 
datapallas.ldap.group-role-map.DataPallas-Admins=ADMIN
datapallas.ldap.group-role-map.DataPallas-Authors=REPORT_AUTHOR
datapallas.ldap.default-role=JOB_OPERATOR

Okta, Auth0, Keycloak, Authentik, Zitadel

These follow the Entra pattern: register DataPallas as a web application at the provider with the redirect URL https://<your-datapallas-host>:9090/login/oauth2/code/<name>, add a groups claim to the ID token (providers do not send one by default), and use the provider's issuer URL. Keycloak is the easiest choice if you have no identity provider yet — it is free, self-hosted, and maps groups to roles cleanly.

Google Workspace

Sign-in works the same way, with one limitation that is Google's: Google does not tell applications which groups a person belongs to. People sign in with their Google account, and you set their DataPallas role yourself on the Users screen.

Your Own LDAP Directory

OpenLDAP, lldap, 389 Directory Server and ApacheDS all work:

datapallas.ldap.enabled=true
datapallas.ldap.url=ldap://ldap.corp.local:389
datapallas.ldap.base-dn=dc=corp,dc=local
datapallas.ldap.user-dn-patterns=uid={0},ou=people
 
datapallas.ldap.group-search-base=ou=groups
datapallas.ldap.group-search-filter=(member={0})
datapallas.ldap.group-role-map.DataPallas-Admins=ADMIN
datapallas.ldap.default-role=JOB_OPERATOR

What Is Not Supported

• SAML 2.0 — use the OIDC route above; nearly every product that speaks SAML also speaks OIDC. If you have a SAML-only provider, get in touch.
• Automatic joiner/leaver provisioning (SCIM) — DataPallas creates a person's record the first time they sign in instead.

The AI Hub Comes Along

You do not configure sign-in twice. Explore Data & Build Dashboards keeps no accounts of its own: its sign-in form checks with DataPallas Server, and signing in to either app signs you in to both.

• With Active Directory or LDAP, people sign in to the AI Hub's form with their directory username and password, as on the main login page.
• With a "Sign in with …" provider, the AI Hub's form has no such button. People sign in on the main DataPallas login page first; when they then open the AI Hub, they are already signed in.

What a person may do in it follows their role, as in the table above.

Troubleshooting

Next Steps

• Installation & Setup — install DataPallas Server
• Scheduling & Automation — run reports hands-off
• DataPallas Server Overview — Desktop and Server compared