Project Configuration

Basic Settings

Click to change your project name easily.

Project variables

The Project Variables section allows you to define your own Setting fields. Then, within each Portal you can give this Setting its own Portal-related value.

The Value you give Setting fields for each portal, can be retrieved in the logic of your project using an expression with the function Setting("fieldname"), which at that point will yield the value for the active portal.

So in a way a Project Variable is a variable setting you can define yourself, to hold a value per portal within the project. Its type is always text, and its value is read-only within the logic of the project.

To remove a Project Variable (and all its Portal-level values), click to the left edge of the item to select it and make [x Delete] button becomes available. Then click on the [x Delete] button to remove the project variable.


Here you can add and manage languages to be available in your project.

An overlay shows the languages already in your project and a button to add more. Clicking [+ Add Language] shows another screen with a dropdown of available languages and a formatting example of the selected option.

If you hover over an already available language, an [x] button appears on the right. Click that [x] to remove the language from the list of available languages.


Storage strategy

Portals within a project can either share the data (in the Runtime) or have each their own separated storage.

If the various portals in a project all need their own data and/or prevent users from the other portals to access the data (like with a multi-tenant solution), you should choose to separate the databases (each portal its own storage). On the other hand, if the users of the various portals can or even must share the data, you share the database (this is the default setting when creating a new project).

NOTE: you can only specify the storage strategy (shared or separate), at the time when you create the project or shortly thereafter.

This setting cannot be changed once the project is previewed or published - because either of those actions will create the database container based on the chosen strategy - and, once the container has been created, it cannot be changed.

Google Analytics

WEM supports Google Analytics. This is the basic version of Google Analytics (not the more advanced AdWords or other features). For information about GA, visit

This implementation for Google Analytics will no longer be supported by Google from July 2024!

A better approach - if you want to support the latest Google Analytics - is to use a Design Template that has the support for the current Google Analytics (or Tag Manager) embedded with a parameterized property for the Google Account ID.

The Design Template Customizable Main has this feature available (it is the only Design Template with this option), so if you use that Design Template, set the Google - Enable Tag Manager option to true (or based on hostname or other situations) and set the Google - Tag ID value accordingly.

If you want to use this feature in your own Custom Design Template, use the WMT tool to get a copy of the Customizable Main template to see the implementation and implement it into your own Custom Template. You will need the correct script to insert from Google, depending on your chosen service from Google Analytics. Use the example in the Customizable Main file mastertemplate.bwmt to see the proper way to make the parameters for the script itself and the Google Account ID.

An example:

<? Placeholder "GoogleTagSupport" default false
<!-- Google tag (gtag.js) -->
<script async src="<% Placeholder "GoogleTagId" default "" %>"></script>
        window.dataLayer = window.dataLayer || [];
	function gtag(){dataLayer.push(arguments);}
	  gtag('js', new Date());
	  gtag('config', '<% Placeholder "GoogleTagId" default "" %>');

When you switch the Google Analytics support to ON, a new Project Variable is created: ["Google Analytics: Tracking ID"]. So now you can go back to the Project Variables configuration page, to enter your Tracking ID which you should have generated in the Google Analytics Account and linked to the hostname that you will be using for the portal.

The value that you provide here, will be inserted into every page (every full-page Interaction Node) that is part of your portal. Every time a user visits that page, you will see this reflected in Google Analytics by its Node ID (the ID of the interaction node, which you can also use to search in the Project Flowcharts Tree).

Be sure that you create the correct Google Analytics tracking variant, the basic GA.js, and that it is connected to a valid account in Google. Also that it is linked to the correct hostname by which the portal is used in the Live Runtime (no use linking it to preview anyway).

Thereafter, all full-page Interaction Nodes that are visited will automatically be tracked with Google. However, due to GDPR regulations, WEM always uses the AnonymizeIP setting (check the Google documentation on what this means).

Next, there are 2 additional Process Nodes available, [Register Action] and [Register Value] with which you can send specific action or values to Google Analytics. The process [Register Value] can be used to register specific page names for example, in case you want to register Overlays (which are not full-page, so not automatically logged) or if you want to register certain pages by a human readable name instead of the node-id, to make GA-reports make more sense.

Query string

Query string parameters are name+value pairs added to the URL ( in the browser address bar (or to a link you click on) after the questionmark [?] indicating the end of the path and the start of the parameters. Check this wiki for information. Let's look at this URL:

This URL contains two parameters: uid and action. The values are associated (passed) with the parameters you may want to use in your project.

Using the Project Configuration for Query String Parameters, you can define which parameters your project expects and to which fields in the Project's Data model the values are mapped. These can only be fields of type Text and may not be part of a list (because at the point of mapping from the request, there cannot be an active row on that list to put the values in).

Any parameter that is provided in the URL, but not defined as parameter in the WEM Project, will be ignored.

When the parameters are mapped to fields in the Data model, you can use these fields in your expressions and flows (and be smart to check if they have a value when you do - using the HasValue() function).

Query string Parameters can also be defined on specific Navigation Items (that have a URL-path defined and a deeplink with a flowchart linked) - of course via the context-menu on the navigation item.

The difference between the Parameters on Project level and the Navigation Item level, is that the Parameters on Project level can be used with every path within the Portal. The Parameters defined on a specific Navigation Item will only work when they are combined with the specific path of that navigation item, and then only in the Flowchart linked to this navigation item; not anywhere else.

Project Features

This part allows you to make changes to certain Project Features. This is introduced to support specific features available to WEM Kubernetes Runtimes (mostly Private Clouds, not yet available on the standard shared clouds for EUR and APAC).

Relative URL paths

When you create navigation items, a path will be created using the name of the navigation item that will be added to the staging and live hostnames, so it can be used as a direct link to that specific navigation item. Navigation Items can be nested to a few levels, and the "old - legacy" way to generate URL Paths is "absolute", where only one level was created - a combination of hostname + navigation item name. The new way which is also standard for new projects, is to create relative paths, which creates several levels.

Last updated