The Metadata manager allows you to add, remove, customize, or re-order the fields for most of the modules and functionalities in Backstage.
For example, the User module by default contains the First name, Last name, Company, Position, Email, Phone number, etc. fields. These are all metadata that can be managed via the Metadata manager, to better serve your workspace.
This can allow you to capture additional data in your workspace by adding or editing fields to modules, and to configure targeting for your workspace content in order to decide what your app users can see or access in the app.
This tool can make significant changes to the way data is structured in your workspace and in the app, so please only use this if you are confident about what you are doing.
Using the metadata manager
To access the Metadata manager in Backstage, from a workspace, go to Settings > Metadata.
Selecting a module
The first thing you need to do in the Metadata manager is to select the module or functionality for which you would like to manage the metadata.
Click on the dropdown list at the top of the screen, and type in the name of the module or functionality you are looking for to find it:
In this article, for the purpose of explaining how the Metadata manager works, we will select the Users module. Below we will explain how each section of the metadata manager works, and the fields they contain.
Representation - or configuring the information contained headers in the app
The Representation section is used to determine how the entries for each module (users, speakers, sessions, sponsors, meetings, etc.) will be displayed to attendees primarily in the app, and mainly in the profile header:
For example:
-
In Users:
Take a look at the below configuration in the Representation section, for the Users module.Here we have selected what fields will appear in the first, second, and third lines in the profile header in the app, using the user's first name, last name, email address, position, and company metadata.
The above configuration will result in the user profile information looking like this in the app (look at the order of the information):
The metadata used here, between {{...}} brackets (fname, lname, etc.), is taken from the Fields section of the Metadata manager.
To note, starting November 11, 2025, the User metadata configured in the Representation section will also be shown when scheduling meetings using the Appointments module. This is applicable when viewing meeting details, selecting participant calendars, and selecting participants to add to meetings in Backstage and in the app. For example here in the web app when adding a participant:
- In Speakers:
- In Sponsors:
Note: This determines how the information will be displayed in the page headers. It does not determine what information will be displayed in a list when displayed in the app, which is done via the Link appearance in the Preferences section of each module.
In addition to the page headers ( as described above), the Representation section also determines what information will be visible when selecting a user to be added to meetings.
Configuring the fields in the module
After selecting your module, in the Fields section you will see all the fields (or metadata) that will be displayed and available for use in that module within your module interface in Backstage, for any item created there.
Below are the fields available by default in the Users module, as seen in the Metadata manager:
Field name |
Metadata |
First name |
{{{fname}}} |
Last name |
{{{lname}}} |
Position |
{{{position}}} |
Email address |
{{{email}}} |
Organization |
{{{company}}} |
Department |
{{{department}}} |
Specialty |
{{{specialty}}} |
Phone number |
{{{phone}}} |
Mobile phone number |
{{{mobile}}} |
Address |
{{{address}}} |
Country |
{{{country}}} |
City |
{{{city}}} |
Region/State |
{{{region_state}}} |
ZIP code |
{{{company}}} |
Keep in mind that metadata can be customized in the workspace by editing the default metadata or deleting or creating new metadata. This metadata can also be used as merge tags in app pages and emails.
The User metadata is shown as follows in the Metadata manager:
And this is how the above fields look in the User's module interface in Backstage:
The columns and fields displayed in the Metadata manager are further explained below, from left to right:
Field name
This is the unique identifier for the metadata. It can only be in lower case and no special characters, spaces, or dots "." can be used. Instead of using spaces here you can use an underscore, e.g. "flight_departure".
This is also the text that needs to be placed in curly brackets {{___}} to be used in the Representation section, as shown above.
Beneath the "Field name", you cab use the dropdown to assign the metadata to an existing category. More information on categories
Restricted fields names that should not be used:
Please note that some metadata field names are already used by default by the metadata manager for various functionalities, and should not be used for creating custom metadata.
Please follow the below rules to avoid any issues with your custom metadata:
- Do not create any custom metadata with field names that start with: "_" or "fp_"
- Do not create any metadata with fields names that match the following:
- is_team_member
- self_registered
- waitlist
- sessions
Field kind
Here you can select what type of metadata (or input data) the user will be using in the field.
There are many types for you to choose from in the dropdown list, that allow you to customize the fields in the module.
When an existing field’s "kind" or "type" is changed, the corresponding data in the workspace (users, speakers, sessions, etc.) will need to be exported and then re-imported in order to save this field’s values with the new (modified) field kind/type.
The different field kinds are explained below:
AUTO
This is usually for data generated automatically by the system. Automatically generated data should not be changed by the user, and if a metadata has been populated using “Auto” then the value will not be modified when performing an import.
BOOLEAN
This adds a checkbox to be used for the field.
CHOICE
Create a field that has multiple choice options that app users can select using radio buttons.
Creating choice options:
Click on the Edit button:
Now you can add the selectable choice options, with each individual choice option using a bullet point in the field, like in the example below that has two choice options. You can add as many choice options as you need:
After saving, the configured choice options appear in the preview to the top right of the metadata.
You can also see that the added choice options field (edited in the previous step) have been populated:
When the field looks locked, these items can be edited again by clicking the Edit button, allowing you to make any necessary changes to the values and keys (but not the translation keys).
Important: Please see onscreen above (in blue) the explanation of what you are seeing greyed out in the added choice options:
“The text shown before the brackets are the labels displayed in the app, this can be updated any time. The text shown in brackets are the keys, if you have already applied targeting DO NOT update the keys, this will break your targeting.”
Difference between the choice "value" / "key", and "translation":
The choice value is the text that will be actual visible to the app user
The choice key is what the system uses to uniquely identify this choice, and is for targeting, among others. By default (unless you use the syntax described below) it is automatically created identically to how the choice value is typed.
The choice translation key is used to identify the translations for this text in the system.
Example:
- Choice value = "Nurse’s aid"
- Choice key (what we use to uniquely identify this choice = 'Nurse’s aid'
- Choice translation key = "Nurse__s aid". This is not visible here in Backstage, and is only visible in Backstage in the Translation manager.
Using special characters:
To better support special characters, please note that any special character used in the choice key will be converted to a "double underscore" (__) in the translation key.
The following are not considered special characters, and do not get converted to double underscores in the translation key: letters / numbers / spaces / underscores (_) / dashes (-).
Examples of characters that get converted to double underscores in translation keys: mentions (@), hashtags (#), dollars ($), commas (,), apostrophes (' or “), parentheses (()).
Important: If you have a choice list with a special character on an existing workspace, and you want to update that metadata, please make sure to recheck your translations, as the related translation keys will be recreated using underscores, and you will therefore need to add the translations again. if you do not change the metadata, then no action is needed.
Using a syntax to distinguish the choice "value" from the choice "key":
Ideally, you should use choice options that you are not likely to edit later on once they are already in use in the workspace, as this can cause issues if you are using targeting, for example.
If you do expect that you will need to edit a choice value once it is in use, you can use the syntax that is described below to create a distinct key value for it.
The syntax works as follows:
Example: "- I want to discover new products (key='products')"
Here, "I want to discover new products" is the choice value that users will actually see displayed, while 'products' is the corresponding choice key for this choice option. This choice key was chosen by the Backstage user and is saved in Backstage, and is in particular used for setting up targeting.
Important: Please make sure that you always use single apostrophes (') and not double apostrophes (") for the choice key.
Having this distinction between the visible choice text and its corresponding value in Backstage means that Backstage users can safely modify the visible choice text without modifying the value, which means that any targeting that is set up will not be affected by the change, as only the value for the choice option is used for the targeting rules.
When using this syntax, there are no constraints (maximum or minimum number of characters) for the choice option's displayed text or for its corresponding value. They can be as long or as short as you like (including using an individual character, and they can also be identical (the visible text can fully match the label if needed). The only constraint that must be followed is the following syntax:
"- replace with displayed choice text (key='replace with corresponding value')"
The above CHOICE descriptions also fully appy to the CHOICE LIST field type (see below).
CHOICE LIST
This works the same as the Choice type explained above, however the user will select their choice in a dropdown list instead of radio buttons.
You can edit the contents of the drop downs for the "Choice" and "Choice list" field types. Just click on the "pencil" button, and the drop down list content will become editable like a text box. This allows you to easily modify the order of items, and even copy and paste the full content from one field to another. Do not forget to click on the check mark to save the changes done when editing a checklist.
COLOR
This allows a hex color code to be added as a value to the field.
CONTENT-PAGE
This is used to select a previously created content page.
DISPLAY ONLY
This means that the field in Backstage cannot be edited by the Backstage user. It is only displayed.
EMAIL
Allows you to only enter a valid email address as a value. This field will require that the added data contains a "@", and will also by default be mandatory.
SPOTME OBJECT
Allows you to select a SpotMe content type as a field.
FORMATTED DATETIME
Used in registration pages, to add and configure a date and time picker for your registrants to complete. Find out more.
Used with integrations such as Cvent, to configure how certain travel or hotel dates and times can be imported and formatted. Find out more
HIDDEN
Hides the metadata from both Backstage and the app but it remains visible in the metadata manager if the user wants to restore it later on.
HTML
Enables HMTL language to be used within the metadata field. With HTML you can easily format your fields with paragraphs of text for example.
List
Can add multiple value fields with predefined kind.
NESTED-OBJECT
This used to edit the properties of objects that are nested within pages.
NUMBER
Only numbers can be entered in this type of field.
PASSWORD
Allows a password to be entered that is hidden from view, and displayed as "•••••••••••••".
NUMBER
Only numbers can be entered in this type of field.
TEXT MULTILINE
Allows a larger body of text to be entered in a field, and to use line breaks (using the Enter key) that will be visible only when seeing the field in Backstage. This field type should not be used for displaying content to app users.
TEXT
Only text and numbers can be used.
TIMESTAMP
This is used to add values to the field in date/time format.
VIDEO-CALL
This is used to add a "Start a video call" button to a page or profile.
Label, tooltip & placeholder
On the top line there is the "Label": this is the name of the field as seen in Backstage and the app (when applicable).
On the second line is the "Tooltip": this can be used to add additional information for that field and will only be visible in Backstage.
On the third line is the "Placeholder": this is text that will be pre-filled in the field to provide an example of the data that the field can hold. Placeholders can be used for all metadata types except Auto / Boolean / Choice / List / Nested objects / Timestamps / Video call. Placeholders, when populated, are currently not visible in the pages in Backstage (this will be remedied in the next release).
Is required checkbox
If this checkbox is ticked then the metadata field has to have a value added.
Preview and default value
You can set a specific default value that populates the metadata field when no data is added. You will also see a preview of how the value looks in the field.
Private checkbox
This checkbox indicates if the field should be private, and therefore not visible to other app users unless certain requirements are met. for example, an email address in a User profile is not visible until the user has shared their business card via the app.
When a field’s privacy is changed from private to public or the other way around, the users list will need to be exported and then reimported in order for the new metadata to be correctly saved as private/public after the change.
Prevent in app modification
This check box can be used to ensure that, if a metadata or corresponding field is added to a place in the app, the user cannot under any circumstances modify the information in the field:
When seen on the app, the fields that have the Prevent in app modification checkbox option enabled are visible, but are greyed out and cannot be edited:
Examples of use cases:
- Prevent in app modification on User metadata: You can apply this to a field that you would not want your attendee to be able to modify in their user profile, this could for example be assigned group number or table number. It is important for them to see this information in their profile, but also important that they do not edit it.
- Prevent in app modification on Meeting metadata (used in the Appointments module only): You can apply this to the fields of meetings, so that app users can see information but cannot modify it. For example, your event’s meetings are set-up in advance, with designated organizers, and you do not want the organizers to be able to change the location of the meetings, and/or the date and time.
Adding new metadata fields and categories
To create a new metadata or category for the selected module, simply click on the Add field + or Add category button at the bottom of the screen:
When you create a new field, you will need to select a category for the field to belong to, and then enter the details fort the field. Here you can add a Field name, Label, etc. based on the indications provided above.
You can also create categories to add metadata to. When you create a category, you will need to give it a name. Categories will create separate sections in the user interface layout, and when a metadata is associated with a category it will appear in that section of the layout.
Moving categories and metadata fields
The order of the metadata fields and the categories that they belong to can be modified. For example, moving a metadata field to the top of the list here will make the field display at the top of the user interface in Backstage.
This is done by dragging and dropping the items, by selecting the ≡ icon and then moving the item up or down:
You can also move a field to the top of its category by clicking on the ⋮ button to the right, and selected "Move on top".
Deleting metadata
You can delete metadata by clicking on the bin icon to the right of the metadata listed in the Fields section:
Comments
0 comments
Please sign in to leave a comment.