What we call things we see or use matters. Because words matter. And we shouldn’t call the same things by different names. The BRYTER platform has grown and so have all components and the terms we use to refer to them.
To make training and finding solutions to your challenges and problems quicker, we have created this glossary so you know how to refer to components and can search more effectively.
⬜ Wizard – everything your end-user sees and interacts with
Wizard (or end-user interface) is the term used to refer to what the end-user interacts with. This could be an Application consisting of published Modules or Data Views.
Terms |
Definition |
|---|---|
| Application |
The digital service an author builds and publishes to be used by end-users. An Application can consist of multiple published Modules, Data Views, published Applications, and/or custom solutions. |
| Authenticated user | End-user with an attributed user role that exists in the tenant and needs to log into BRYTER to use an Application built with BRYTER. |
| End-user | Anyone who uses a published BRYTER Application. End-users are your intended audience. |
| Wizard (End-user interface) | User interface type that presents a user with a sequence of dialog boxes that lead the user through a series of author-defined steps or a Data View with stored records and an action. |
| Environment | A publishing stage and context for executing a Module and separating data, either in TEST for testing the Module, or LIVE for using a published Module for real end-user interaction. |
| Link back | Link used in the content field of an Input Node to return the end-user to a previously seen user input. Newly entered or amended values will overwrite previous session data. |
| Published data view | A web-based user interface that authors can make available to end-users through the Portal or by embedding/linking to it. Data Views can be configured to show a filtered table of records from an underlying Case Database and to offer actions on those records. |
| Published Module | A Module that can be executed in a TEST or LIVE Environment through a distinct URL. |
| Session | One execution of a published Module that leads to data creation (unless disabled). |
| Session data | The values entered by the end-user, or output by integrations, actions, and document generation, are recorded during a session. |
| Theme | A theme is the preset graphical appearance of a published Module. Themes can be created in the Admin Console by admins and selected in the Publication Suite by authors. |
⬛ Workspace – everything you see after logging in for the first time
The first interface an author or admin sees when logging into BRYTER. Part of BRYTER that admins use to access the Admin Console or authors use to build their Applications with BRYTER: Creating and managing Applications, editing Modules in the no-code Editor, configuring Data Views, Case Databases, and published Applications.
Terms |
Definition |
|---|---|
| Admin | An admin has access to the same functionality of BRYTER as an author, plus the rights to access the Admin Console. |
| Admin Console | The interface for BRYTER admins to manage their tenant. |
| Author | A user role that is using the BRYTER interface to create, configure or modify any component of an Application (Modules, Case Database, Data Views, published Applications). |
| Case Database | An author-configurable data store within the BRYTER product, whose primary purpose is to store records, with data separated by environment. Not a database hosted outside BRYTER. |
| Collaborator | An author (or admin) who has access to an Application in BRYTER. Collaborators can create or amend or delete all Application components in the Application where they are part of the collaborator list. |
| Data Views | A web-based user interface that authors can make available to end-users through the Portal or by embedding/linking to it. Data views can be configured to show a filtered table of records from an underlying Case Database and to offer actions on those records. |
| Help (Center) | Access to the BRYTER Support Center where authors and admins can find feature documentation, tutorials, and best practices to help with the creation of Applications. |
| Module | The collective individual entity containing logic, content, and presentation that is worked on by authors within BRYTER. This includes the construction of the graph, Integrations with Action Nodes, and the presentation via the Wizard. |
| Resources | Hyperlinks to useful web pages such as the Use Case List on the BRYTER website, the Learning Journey, Academy or another way to enter the Help Center. |
| Application | The use case authors automate and build with BRYTER and the thing that end-users consume. An Application contains any number of related Modules and Case Databases to implement a single use case. |
| Application Components | Application components describe published and unpublished Modules, Case Databases, and Data Views within a single Application. |
| Published Application |
A published Application is a stand-alone page that merges different entry points to an Application and enables business experts to deliver several components of an Application to their end-users. End-users can navigate easily between the individual components. |
| Applications List | List of all Applications where the person logged in is a collaborator. The list is ordered by displaying the most recently updated Applications at the top. |
| (Application) Template | An Application that is read-only until duplicated by an author. Templates are created by the business consulting team at BRYTER and can serve as a starting point for building one’s own Applications. |
| Templates List | All templates that have been made available for authors to get inspiration on use cases and best building practices or as a starting point for their own use case ideas. |
| Use Cases | A specific situation, process, or list of actions and event steps for which BRYTER could be used. A use case is commonly depicted with several Modules, Case Databases, and Data Views in one Application. |
| User | A user role that, unlike end-users in general, encompasses selected internal users within the organization. Compared to admins and authors, users cannot create, configure, or modify any component of an Application. |
⤴️ No-Code Editor – where you build your Modules
A web-based, no-code Editor to create a decision tree with Actions, user Inputs, Values, and Results. The editor supports standard programming functions like variables and collections and adds specialized functionality like a powerful date calculator and excel-like functions. The heart of the editor is its easy UX, which enables non-tech people to easily model complex knowledge. For advanced users, a debugger and quick check is provided.
Terms |
Definition |
|---|---|
| Action Node | A building block that is geared towards generating or processing data. Unlike Input Nodes that are outward-facing, Action Nodes, like Value Nodes, are inward-facing, i.e., perform operations that are not visible to the end-user. Action Nodes are distinct from Value Nodes in that they "do" something, i.e., initialize or progress a process, whereas Value Nodes are used to simply "set" or "create" values for later use. |
| Build (Mode) | The default editor interface that is mainly used to build, i.e., create Modules. In contrast, another available mode is "Inspect mode" which is mainly used for testing and debugging an already built Module. |
| Built-in Values | When a BRYTER Module is set to "Only accessible after login", built-in values can be used anywhere from different types of Nodes to the conditional logic of a Module through @-referencing. Built-in values include the Session ID, User Email, and different variations of a user’s name (i.e., Full name, Given name, Last name). |
| Collections |
Setting in Input Nodes that enables to dynamically collect the appropriate number of responses for a certain question. End-users can add up to 20 entries in the published Module. |
| Condition | Shapes the core logic behind a Module and can be used to determine the end-user's path through a Module in Transitions or used locally to affect content in Conditional Blocks. |
| Content | The field of a Node in which authors can make available information to their Module’s end-users. |
| Data source |
A named data query which structure remains independent of the software that provides the data. Query results typically populate a list of options to select from, each with a name and ID that typically refers to external data that Modules can reference. Data sources can be set up by BRYTER admins in the Admin Console and used in single-select Input Nodes. |
| Default value | Pre-filled answers in Input Nodes that can be kept or changed by end-users. |
| Document Template | Select the BRYTER default or upload a custom template (only DOCX) to generate and/or automate documents using placeholders. |
| Document View | Allows displaying a PDF document in the published Module next to the published Module end-user interface. |
| Fields | Column in Module overview that shows the options of Input Nodes, selected or typed in values in Action Nodes, and selected toggles or URL Parameters in Result Nodes. |
| File | Enables authors to upload a file in the content field of Input, Result, or Value Nodes which can be downloaded by end-users. |
| Go To Picker | Enables authors to change the destination of a Transition quickly, as well as, to search for the correct destination Node. |
| Group | Nodes can be "grouped" together to make complex Modules easier to read and scroll. Groups can be expanded and collapsed. |
| Handover Node | This building block is a hybrid between an Input Node and an Action Node and enables authors to initiate a handover process at a specific position in a Module. |
| History | Allows access to different versions of a Module, e.g., to restore an earlier version. |
| Info Block |
Can be used by authors to provide end-users with hints, disclaimers, or additional information. |
| Input | Information provided by the Module’s end-user through selection or entry. |
| Input Node | A building block that is outward-facing and typically poses a question and requires a response from an end-user. |
| Input Preview | Is displayed below the content field when an Input Node is set to "Text", "Email Address", "Number", or "Date". It reflects the state and appearance of the input which will be presented to the end-user. |
| Inspect (Mode) | This mode enables authors to inspect their Modules quicker and easier: they can trace the execution of their Modules, simulate the execution of Integrations, and provide mock data for Database Nodes. In contrast, the default mode in which a Module is created is "Build mode". |
| Inspect Session | When simulations are run in Inspect mode, a so-called Inspect Session is recorded detailing the walk-through, including any type of Nodes that have been passed, as well as the underlying conditional logic. |
| Integrations | BRYTER allows for the Integration of most custom tools and databases. These Integrations can be added to Modules as actions. |
| Label | Supports understanding the context of input fields and enables people with visual impairment to navigate the wizard confidently with screen readers. |
| Module Overview | An additional view in which the content of all Nodes and the Conditions applied on Transitions are displayed in a tabular list. |
| Module Summary (or Info) | Module authors can include information about the Module to remind them of its purpose, its status or review dates, contact details, or to communicate with other collaborators around the process. |
| Node | Basic building blocks of a Module. |
| (Node) Type | Represents the different functions of each building block. |
| (Input) Options | Are displayed below the content field when an Input Node is set to "Single select" or "Multiple select". |
| Preview | An advanced view of the Wizard (end-user interface), showing what end-users will see once the Module is published. |
| Publish | Enables Module authors to share Modules to TEST and LIVE Environments for use by internal colleagues and/or external users. |
| Quick Check | A real-time helper for Modules to help highlight and fix common errors and offer suggestions on how to resolve potential issues. |
| Result Node | Usually signifies the endpoint of a Module and can include anything from a summary, download, or even a redirect to a different Module or website. |
| Search | Enables Module authors to look up specific keywords used in the Module as it scans for Node names, notes, and even Transitions, highlighting matches in green color. |
| Transition | Link the different Nodes to enable end-users to navigate through the Module using logical Conditions. |
| Undo/Redo | Reverse or restore a previous edit. |
| Value | Can represent any variable that is used in a Module. A Value Node is a certain type of building block that "sets" or "creates" values for later use. |
| Value Node | This building block can be set to a number, a date, a text block, or an email address. While Input Nodes are outward-facing by posing a question and requiring a response from an end-user, Action Nodes and Value Nodes are inward-facing. The main difference between the latter is that Action Nodes "do" something, i.e., initialize or progress a process, whereas Value Nodes are used to simply "set" or "create" values for later use. |
| Value Picker | The variable browser or "Value Picker" helps to find the relevant value to reference and can be accessed by typing "@" or selecting "@ value" in the navigation bar of the content field of a Node. |
| Zoom | Allows for displaying of smaller, detailed views or bigger, broader views of a Module for easy navigation. |
📄 Document Automation – how you generate documents
BRYTER harnesses the power of Microsoft Word, to offer one of the most easy-to-use, yet powerful document generation products on the market. Document templates can be created directly in Word and then enriched by values from the BRYTER visual programming editor. This allows complex reasoning, but still guarantees the rich formatting options and UX of Word.
All documents can be created and offered as download (docx or pdf) with one click.
Terms |
Definition |
|---|---|
| Command | Instruction in an uploaded template for document generation that deletes a paragraph in empty lines, columns, and rows or inserts a comment inside the document for other collaborators. |
| Placeholder | Temporarily marks and holds a space until it can be filled with the necessary input. (Not to be confused with the greyed-out text that appears in a field and gives end-users a hint about what they could enter.) |
| Template | A raw document that through the integration of placeholders and commands allows for swift and dynamic document generation and automation. |
🗄 Case Databases and Data Views – how you enable case management
If you offer an Application, it is seldom a one-way street. Applications often consist of an intake process, a review step, lists of incoming requests, and analytics dashboards. BRYTER's case management capabilities enable you to create these complex processes and workflows, visualize them and apply granular access management, so only the information needed is displayed to those who are responsible. And everything without writing a single line of code.
Terms |
Definition |
|---|---|
| Action | An action button can be configured for each record in a Data View and typically allows further processing of this record in a BRYTER Module. |
| Case Database | An author-configurable data store in a BRYTER Application that enables authors to store (case) records. |
| Case Database Configuration | An interface that enables Authors to add or edit Case Database fields to a Case Database designed to store data from published Modules. In the Case Database configuration, Case Database fields need to be specified with a field name and their type. |
| Case Database Data Viewer | Depiction of data saved in a Case Database only accessible for collaborators of an Application. Records created in the TEST and LIVE environment are available in separate tables and available for CSV export. |
| Case Database Fields | Each item of information in a Case Database record stored in an individual column. Case Database fields have unique names and an associate type of value available to be stored in the field (Text, Date, Number, Email, File) |
| Data View | A web-based user interface that authors can make available to end-users through the portal or by embedding/linking to it. Data Views can be configured to show a filtered table of records from an underlying Case Database and to offer actions on those records. |
| Data View Fields | Information stored in a Case Database field that appears in a Data View. |
| Filter Records | Filters which records or rows of the underlying Case Database will be displayed based on the content in the Case Database. |
| Last Update | This is an automatic database field. It can be used to sort records in the Case Database and connected Data Views. |
| Record | Each row with a unique identifier stored in a Case Database. |
| Published Application |
A Published Application is a stand-alone page that merges different “entry points” to an Application and enables business experts to deliver complete Applications to their end-users. |
| Published Application Configuration | Authors interface to create one published Application per Application by selecting individual components that will be included on the page such as Modules and Data Views. |
| Type | Category for the value stored in a Case Database field captured in the connected Module. Available value types include Text, Date, Number, Email, and File. |
| Unique Identifier | This is a mandatory unique database field. The unique identifier is the way to access individual database records later. You can also rename it if you already use another unique identifier for your case. |
| URL Parameters | Allow getting data from the outside environment. When a Module is embedded in an intranet solution, it can use data from this solution and place it in the Module. |
🚀 Publication Suite – how you make Applications available to end-users
A key component in automating an Application is to make it accessible to others. BRYTER offers an extensive publication suite that enables you to publish an Application in various formats: As a stand-alone website, as a responsive mobile web app, MS Teams and SharePoint apps, or embeddable in your intranet. The look and feel of everything you build can be easily customized with our Theme Editor. Also included are different publishing environments: one to test, and one to run your ready Applications.
Terms |
Definition |
|---|---|
| Access Settings | An action button can be configured for each record in a Data View and typically allows further processing of this record in a BRYTER Module. |
| Configure (Published Module Configuration) | Configure published Modules to show or hide the following features: Navigation, progress bar, and scroll assist. |
| Custom Theme | Toggle on this option to select a custom theme from the dropdown menu. The BRYTER solution comes prepackaged with two BRYTER themes: BRYTER and BRYTER Black. |
| Development (Environment) | The default environment and a pre-publishing. |
| Do not save user answers | Select this option to prevent user answers from being saved in the Module’s logs and stats. |
| General Settings | Apply to the Module overall and will take effect in both the TEST and LIVE environments of the Module. |
| LIVE (Environment) | A publishing stage and context for executing Module, either in TEST for testing the Module, or LIVE for using a published Module for real end-user interaction. |
| Save and Continue Later | If this option is enabled, users will see a link at the bottom of their Module labeled Save and continue. When a user follows this link a personalized URL is created that can be used to return to the Module at a later time. |
| TEST (Environment) | A publishing stage and context for executing Module, either in TEST for testing the Module, or LIVE for using a published Module for real end-user interaction. |
| Preview | An advance view of the Wizard (end-user interface), showing what end-users will see once the Module is published. |
⚙ Admin Console – how you manage and configure your BRYTER tenant
Administrators can use a web interface to configure their BRYTER tenant. This includes user management, access audit logs, managing and styling of tenant-wide themes, manage integrations as well as getting usage insight through tenant analytics.
Terms |
Definition |
|---|---|
| Admin |
An admin has access to the same functionality of BRYTER as an author, plus the possibility to access the Admin Console. |
| Audit log |
The audit log is a complete log of all the events (user and Application/Module/database creation or deletion) that have been recorded in your BRYTER organization. |
| Author | A user role that is using the BRYTER interface to create, configure or modify a Module, database, or Application (a persona). |
| Data source |
A named data query whose structure remains independent of the software that provides the data. Query results typically populate a list of options to select from, each with a name and ID that typically refers to external data that Modules can reference. For example, the Kira integration provides a data source that lists documents stored in Kira. |
| Groups | For easier access management to Modules for collaborators. When access is given to the group, any member of the group has access. Members who are added to the group at a later stage will also automatically get access to those Applications. |
| Integrations |
Interface in the Admin Console to add and set up integration types, and their integration configurations and view an overview of all available integrations in the tenant. |
| Integration Catalog | Displays all available integrations and their installation status, name, version, description, and usage. |
| Integration Configurations | Admin interface to add new or edit existing configurations of an integration displaying configuration name, description, type, and version. |
| Integration Types | Interface to add new types for integrations to be added in integration configurations. Displays integration type, versions, and their names. Allows adding new integration types by providing their basic type information, Docker image, parameters, secrets, and authorization. |
| Live Consent Message | Text entered here will be displayed to authors when publishing a Module to Live in the Publish menu. |
| Live Defaults | Configuration of default/pre-selected settings for publishing Modules on the LIVE environment. Authors can adjust these as needed in the Publish Menu. Admins can set defaults in the Admin Console. |
| Organization Activity | Enables admins to analyze the performance of the entire organization over the last 28 days. |
| Settings | Enables admins to customize the interfaces to be seen by authors. |
| Test Consent Message | Text entered here will be displayed to authors when publishing a Module to TEST in the Publish menu. |
| Test Defaults | Configuration of default/pre-selected settings for publishing Modules on the Test environment. Authors can adjust these as needed in the Publish Menu. Admins can set defaults in the Admin Console. |
| Theme Editor | Enables to customize the theme of BRYTER Modules in accordance with the organization's brand requirements or that of the customers. |
| Theme Library | Enables authors to select a theme for their BRYTER Modules. The BRYTER solution comes prepackaged with two BRYTER themes: BRYTER and BRYTER Black. |
| User | A user role that, unlike end-users in general, encompasses selected internal users within the organization. They cannot create, configure, or modify a Module, database, or Application. |
| User role | In the Admin Console, admins can assign one of three different user roles to members of an organization that reflect their respective access privileges. Available user roles are admin, author, and user. |