Using Globals in Server Connect


We added new Global options in the Server Connect panel. The Globals allow you to define and re-use Database Connections and other Settings (1), Variables / Input Parameters (2) and API Action Steps (3) across all your API Actions in the project:

So it’s no longer needed to add these Database Connection or Mailer Setup steps in every server action you need to use a database connection or send an email.

Defining Global Variables / Input Parameters

You can easily define a variable and access it from all your API Actions. One of the most common use cases are the session variables - that’s what our example will show you.
Select Globals and right click $_SESSION:

Create a session variable and add a name for it:

And you are done! Save the changes we made to Globals:

Now you can access the session we defined in your API Actions. Let’s create one - right click API:

Add a name for your API Action and right click steps:

Add a step, which will need the session variable value. We add a Set Value step, just to show you how it works, but this can be any other step:

Click the dynamic data button to select a dynamic value:

You will see the session variable which we defined globally, select it and you are done:

Defining Global Settings

The other Global Settings include Database Connections, Security Provider, Mailer, Oauth2 Provider, S3 Storage and JWT Signing. These can be globally defined and then reused across all your API Actions.

Database Connections

Defining a global database connection is really easy. You can define as many global database connections as your project needs. They will be available for any component which requires a database connection in any of your API Actions.

First, right click the Database Connections under Globals:

And add a database connection:

Add a name for it and then click the Connection Options button:

Enter the database connection details per selected target and click Save:

If you have multiple targets using different database connections, define Connection Options per each of the targets. Just change the active target from the Target dropdown (1) and click the Connection Options button (2):

Then Save the changes:

And you can use this Database Connection in your API Actions.
Right click Steps in your API Action:

And you can directly add a Database Query step:

Select your database connection from the Connection dropdown:

And you are done! You can now setup your query.

Other Global Settings

The other Global Settings can be defined the same way:

Just setup the setting you need and it’s ready to be used across your API Actions:

Defining Global Steps

The Global Steps are steps which will be executed for each of the API Actions in your project. The Global Steps will be executed before your API Action step, so their data will always be available in the API Action Steps:

One useful use case is providing the logged user identity to every server action. So after you’ve setup your global Security Provider:

Just select Globals and right click Steps:

Open the Security Provider menu and select Security Identify:

Select your global Security Provider from the dropdown:

And enable/disable the Output option. Output is useful if you want to access the logged user Identity on your pages - to conditionally show/hide parts of the page for example:

The output, however, is not required if you want to access the user identity in your API Actions - to filter database queries for example.

Click Save and you are done:

The Identify step will run with every API Action and its value will be available for them in the dynamic data picker:


These are the basics of using Globals in Server Action - try them and let us know what do you think :slight_smile:


I am a little confused over Global Steps. Do they automatically get applied to all Server Actions? What if you don’t want it applied to a Server Action?

I am trying to wrap my head around when and why I would use a Global Step?

I wish I had Global Sessions about a month ago. :frowning: :slight_smile:

The global steps - yes.

The most useful case I can think of is getting the user identity and making it available in all server actions :slight_smile:

Then use the library items and include them to the actions you need :slight_smile:

A post was split to a new topic: Global identity from identify action step not working