Skip to main content

Server-Side Variables

Enterprise Plan

Server-side variables let you reference the logged-in user's identity inside your queries and datasource configurations, with the values resolved securely on the server at the moment a query runs. These variables live under globals.server.currentUser and are substituted into your query on the backend, so their values never reach the browser.

Because resolution happens server-side, these variables are safe to use for row-level security, authentication headers, and datasource connection options, where exposing values to the client would be a security risk.

Common Use Cases

  • Row-level filtering: Return only the records that belong to the current user, enforced on the server.
  • Authenticated requests: Inject the user's identity into REST API headers or tokens without exposing it client-side.
  • Per-user connection options: Use the current user's attributes in datasource connection settings.

Prerequisites

  • Server-side variables are available on Enterprise plans only.
  • They can be used only inside the Query Manager, in query bodies and datasource connection options.

How It Works

When you reference a server-side variable in a query, ToolJet does not send its value to the browser. Instead, the raw {{globals.server.currentUser.*}} reference is kept in the query and resolved on the server just before the query executes, using the identity of the user who triggered it.

This means:

  • The resolved value, such as the user's email or ID, is never exposed in the client, in network responses, or in the browser console.
  • Each user's query automatically runs with their own identity, without you having to pass user details from the frontend.

Available Variables

All server-side variables are available under globals.server.currentUser:

VariableTypeDescription
globals.server.currentUser.idstringThe user's unique ID (UUID).
globals.server.currentUser.emailstringThe user's email address.
globals.server.currentUser.firstNamestringThe user's first name.
globals.server.currentUser.lastNamestringThe user's last name.
globals.server.currentUser.rolestringThe user's role name, such as admin, builder, or end-user.
globals.server.currentUser.metadataobjectCustom user metadata stored as key/value attributes.
globals.server.currentUser.ssoUserInfoobjectSSO provider user info, populated for users who signed in through SSO.
globals.server.currentUser.groupsstring[]The names of the groups the user belongs to. The array always begins with all_users, followed by each assigned group.

Using Server-Side Variables

You can reference server-side variables anywhere within the Query Manager using the {{globals.server.currentUser.*}} syntax. When typing inside a query, ToolJet suggests these variables through autocomplete.

Referencing User Attributes

{{globals.server.currentUser.email}}
{{globals.server.currentUser.id}}
{{globals.server.currentUser.role}}
{{globals.server.currentUser.groups}}
{{globals.server.currentUser.metadata.department}}
{{globals.server.currentUser.ssoUserInfo.name}}

Filtering Query Results by User

A common use case is limiting the rows a query returns to those that belong to the current user. Because the email is resolved on the server, users cannot tamper with the filter from the client.

SELECT * FROM orders
WHERE owner_email = '{{globals.server.currentUser.email}}';

This is the foundation for Row Level Security, where you restrict which records a user can see based on their identity or group membership.

Setting Authentication Headers and Connection Options

Server-side variables are also useful in REST API auth headers, request tokens, and datasource connection options, where the value must stay hidden from the client. For example, you can pass the current user's ID as a header value when calling an external service.

Client Side Variables vs Server Side Variables

ToolJet exposes the same user fields through two different variables. The difference is where and how they are resolved.

globals.currentUserglobals.server.currentUser
ResolvedIn the browser (client side)On the server
AvailabilityFreeEnterprise
Where usableAnywhere in the appQuery Manager only
Client exposureValue is available client-sideValue is never sent to the client

Use globals.currentUser when you need user details for UI logic, such as showing or hiding a component. Use globals.server.currentUser when the value must remain secure, such as filtering data or authenticating a request.

info

Because globals.currentUser is resolved in the browser, a user can modify its value before it reaches the server. Never rely on it for security decisions such as row-level security. Use globals.server.currentUser for anything that must be enforced.

Limitations

  • Server-side variables can be used only inside the Query Manager. They are not available in component properties or elsewhere in the app.
  • They cannot be used in RunJS and RunPy queries, since those run code that is not resolved through the server-side substitution flow.


Need Help?