Skip to main content

Glossary of terms

This page contains a list of definitions of common Thinkwise terminology, ordered alphabetically. Technical terms that are not Thinkwise-specific, like database, model-driven, DTAP, CI/CD, machine learning, and branching/merging are not covered by this glossary.

Hyperlinks

Most hyperlinks in this glossary link to other definitions of terms in the glossary itself, not to external pages.

If you would like to read more about a certain concept, we do provide hyperlinks to pages elsewhere in the Thinkwise documentation. These are located at the end of most definitions ("See also...") and are marked with .

Action bar​

An action bar is a screen component that provides quick access to key user actions (CRUD) relevant to the current subject or table. It may also include tasks, reports, cube views, search, or prefilters. See also Action bars.

Advanced filter​

The filter component has two available modes that you can toggle between: default and advanced. The advanced filter is a filter that can take multiple rules into account. These can be combined and nested using AND, OR, and NOR operators. This allows you to build complex scenarios, such as a situation in which one field must meet one condition but another field must meet one of several alternatives. See also Advanced filter pop-up.

Application​

An application is the result of the creation process: a working runtime application version based on your model.

Badge​

A badge is a small visual indicator, typically a count in a bubble or colored highlight, that you can show on subjects, reports, or tasks to draw attention to status or counts. Badge logic is a logic concept that calculates the badge count. See also Business logic in badges.

Base model​

A base model is a reusable model that is only used (through inheritance) by other models. It is not used not for direct development. A base model provides standard elements shared across multiple work models, such as themes, default translations, and shared configurations. You can use base models to maintain consistency and minimize duplication. Linking base models other than the default base models to your work model is optional. You can download some useful models from the Thinkstore. See also Base models.

Branch​

A branch is line of development within a model. It is based on an origin branch at a particular point in time. Using a branch, you can develop features in parallel with other developers or teams.

You can protect a branch, and manage which users can change it. It is also possible to tag a branch as a model version so that it can be used for upgrades or as the source for branching and merging.

Once the work on a branch is complete, it can be merged back into its origin branch (or another branch) to integrate the changes. The branch can then be archived or deleted, unless you are performing a reciprocal merge. See also Models and branches.

Business logic​

Business logic refers to all application-specific logic that cannot be fully modeled declaratively in the visual parts of the Software Factory. This includes not only traditional business rules, but also the logic that controls user interfaces, process flows, messages, and interactions with data. See also Introduction to business logic.

Change detection​

Change detection is a logic concept that allows the application to inform the user interface whether a subject has changed and must be refreshed. It is executed just before the user interface would perform an auto-refresh. The auto-refresh is then only executed if changes have been detected to the subject. This improves your application's performance. See also Change detection.

Code file​

A code file is a source code file that is generated by the Software Factory during the Creation process. It contains the source code of the application's business logic and is stored in the Software Factory. During the Execution step of the Creation process, the code files are executed to produce program objects in the database such as stored procedures and triggers. See also Generate source code.

Code generation​

Code generation is the process in which the Software Factory transforms your defined application model and business logic into executable program objects such as stored procedures, triggers, or functions. Code generation happens during the Generation phase of the Creation process.

It effectively writes the required business logic into deployable source code and database objects. See also Managing code generation with staging tables.

Code group​

A code group is a grouping of control procedures with a similar character, often a logic concept, a subroutine, or a group that exists to support the deployment process, like Upgrade or Manual. Every control procedure that you create must be defined according to a certain code group. Depending on your selection, the Software Factory will generate specific program objects and code definitions later. This determines how the code should behave. See also Code groups.

Connector​

A connector is a special type of process flow action that is used to integrate with external systems using common protocols. It does not expose GUI features, and serves as a bridge between Thinkwise process logic and external systems like databases, APIs, and file services. See also Process flow connectors.

Context​

A context is a logic concept that lets you adapt the user interface at runtime, for example, to enable, disable, or hide tasks and details based on field values or current tab.

A context respects configuration and access constraints. It cannot override model or authorization restrictions. Any UI changes applied (for example, hiding a tab) only persist until the next context execution. See also Context.

Context menu​

Windows GUI The context menu is the menu that appears when you right-click in a form, grid, cube or graph. Click on one of the menu options to execute the described action. The options in the context menu are also available in the ribbon.

Control procedure​

A control procedure defines a specific piece of business logic. It contains the code that is not covered by the standard GUI functionality. With a control procedure, you can define custom actions.

  • It contains one or more associated code templates that define what logic is executed.
  • It defines where and how the logic is applied (for example, to defaults, layouts, contexts, tasks, process flows, etc.).
  • It provides status tracking during development, testing, reviewing, and generation of program objects in the Functionality screen.

A regular control procedure affects your end product, but a meta control procedure affects your model in your Software Factory.

See also Create a control procedure and Control procedure guidelines.

Creation​

Creation is the process during which your application model is transformed into a functioning prototype or deployable artifact.

It consists of the following phases:

See also Creation.

Cube​

A cube is a structured dataset based on a single subject, with multiple clearly defined dimensions (data axes) and values. It is tailored for fast and flexible BI-style analysis and reporting. See also Cubes.

Cube view​

A cube view is a saved visualization configuration for a cube. It defines which dimensions and aggregated values to display and how to present them. This ensures consistent and user-friendly pivot table or chart analysis across the application. See also Set up a cube view.

Custom display type​

A custom display type is a setting that you can apply to objects such as tasks, reports, and prefilters that overrides the default way those objects are shown in the user interface. For example, you can make them appear as icons only, icons plus text, or in the overflow menu.

Data model​

A data model is the abstract structural definition of your application's database scheme. It includes, for example, tables, columns, references, domains, indexes, and versioning settings. Without a data model, your application cannot store input or give output. The data model structures the data which is stored in the database. During the Creation process, the source code of your data model is deployed on the database. See also Data model.

Deep linking​

A deep link is a type of process flow configured to direct users from outside the application to a specific location within it, for example, a subject or a task. See also Deep linking in a process flow.

Default​

Default is a logic concept that automatically sets default values or cursor behavior based on field values during data entry or import. See also Default.

Default filter​

The filter component has two available modes that you can toggle between: default and advanced. The default filter is a filter that you can use for straightforward filtering without nesting and rule groups. For more complex queries, you can switch to advanced mode. See also Default filter pop-up.

Default user group​

A default user group is a pre-configured, reusable user group that includes a set of role assignments. You can set it up as a starting point for a multi-tenant environment so that tenants do not have to do this in IAM. See also Default user groups.

Deployment​

Deployment refers to the phase where your modeled application is moved into environments such as test, acceptance, or production. It includes generating deployable artifacts like installation or upgrade packages, and ensuring that the application becomes operational in the target environment.

Deployment consists of the following stages:

See also Deployment package, Thinkwise Deployment Center, and Automate deployment.

Deployment Center​

The Thinkwise Deployment Center (sometimes referred to as the Deployer) is a tool designed to streamline the deployment of Thinkwise products.

  • Components and applications: You can use the Deployment Center to install and update Thinkwise components like the Software Factory and the Intelligent Application Manager as well as customer-developed applications.
  • Manifest-driven development: You can use a manifest (JSON or YAML) to describe what products are to be included in the deployment package and where their files are located.
  • Unified deployment interface: You can use the Deployment Center via both GUI and CLI.

See also Thinkwise Deployment Center

Deployment package​

A deployment package is a packaged version of your application that can be executed by the Thinkwise Deployment Center. You can easily deploy it to different locations, customers, or tenants. A deployment package is based on a specific branch of your model.

You can start the generation of a deployment package in the Software Factory. The actual creation of the package is done by Indicium. This means that the process can be entirely automated and run in the background. See also Deployment package.

Detail​

A detail refers to a related subject connected to the currently viewed subject. It can be represented in the user interface as a detail tab or detail tile, or it can be reached via the Indicium API. With details, you can model and display one-to-many relationships directly within the user interface. The visibility of details can be managed through context procedures. See also Details.

Detail tab​

A detail tab is a tab within a tab container on the screen that displays the records of a related detail subject for the currently active parent record. With a detail tab, you can view and manage related data seamlessly in the context of the main record. See also Show a detail tab or tile for a table.

Domain​

A domain is a reusable, abstract data type that defines the characteristics of model columns and parameters, including data type, constraints, and UI presentation such as controls. Modifying a domain applies those changes globally across the model. Some domains can contain domain elements. See also Domains.

Domain control​

A domain control is a type of control with which you can specify how a domain should be displayed in the user interface. Examples of domain controls are the checkbox, combobox, datetime, image link, label, location, etc. See also Available domain controls.

Domain element​

Some domains present a pre-defined set of input options, for example, a drop-down list. Each of those options is a domain element. See also Domain elements for COMBO, IMAGE COMBO, and RADIO BUTTON.

Dynamic model​

A dynamic model is an application model that has been built dynamically using meta control procedures instead of the graphical user interface. The queries are run while the application is being built. Dynamic modeling is well-suited for:

  • Adding functionality that applies to several places in the model.
  • Extending the data model.
  • Adjusting the user interface.

A regular control procedure affects your end product, but a meta control procedure affects your model in your Software Factory. A meta control procedure is executed during every generation, and can be made responsible for the objects it maintains. If you only want to make a one-time adjustment to your model or its data, using an enrichment might be a better option. See also Introduction to Dynamic modeling.

Effective rights​

Effective rights are the actual rights that a user or user group effectively has on application objects after combining all assigned roles, permissions, and possibly overrides in the Software Factory and IAM. You can view effective rights in IAM. See also The effective access type explained.

Enrichment​

An enrichment refers to an automated enhancement or generation that jump-starts your application model development. It can automate routine tasks, create scaffolding, and ensure consistency before you manually refine your model.

There are different types of enrichments:

  • Model-driven enrichments scan the model and suggest updates to improve consistency or completeness.
  • Data-driven enrichments prompt for runtime input, then derive model updates based on actual database data, for example, generating missing indexes or populating mock data.
  • AI-powered enrichments use generative AI to automatically generate descriptions, translations, comments, and more.

An enrichment is usually run only once, and it does not maintain the objects that were created during its run. If you want to regenerate or maintain generated objects, using a dynamic model might be a better choice. It is possible to create your own enrichments. See also Model enrichments.

Extended property​

An extended property is a runtime-level configuration parameter used to enable features or behaviors in the Thinkwise Platform that are not (yet) formalized within the Software Factory’s core model. These properties allow you to customize application functionality across different environments, even if the feature is not fully integrated into the base model. Extended properties can be exposed or hidden from the front-end, which is useful for properties that influence back-end or API behavior only. See also Extended properties.

Extender​

See Object model extender.

Fallback area​

A fallback area is the default location for UI components if their assigned screen area is not available in a screen type. It ensures that the UI component remains visible and functional within the user interface. See also Fallback areas.

Form​

A form is a screen component used to display or edit a single record of a subject. Its layout can be customized by configuring properties like number of columns, field spacing, column widths, etc. It is also possible to customize a form conditionally through a layout procedure. See also Form.

Formlist​

A formlist is a screen component that displays the content of multiple rows within a single form, with a scrollbar if needed. See also Formlist.

Function​

A function is a type of subroutine that calculates a result using given inputs. It can return either no value, a scalar value, or a table. A function is reusable and can be called by other logic or external systems. A procedure can call one or multiple functions, but a function cannot call a procedure. See also Introduction to subroutines.

Functionality​

Functionality is the custom business logic of your application. You cannot always model everything using the basic data definitions and UI layout. In that case, you can implement custom behavior using a set of predefined logic concepts.

Functionality is written in the form of control procedures that contain one or more code templates. The Software Factory generates program objects based on those control procedures. See also Functionality.

Function-typed table​

A function-typed table is a read-only table in the data model. Its content is not stored in rows, but is dynamically returned by a table-valued function that the Software Factory generates. It performs especially well when you want to filter your dataset: it filters the dataset based on the input parameters before retrieving it, which improves performance. See also Table-valued function as a table.

Generation strategy​

A generation strategy is a setting defined within control procedures that dictates how generated objects are managed during the Generate definition step of the Creation process. It determines whether, how, and under what conditions these objects are deleted, recreated, or updated. See also Generation strategies.

Grid​

A grid is a screen component that shows multiple records (rows) in a grid layout. See also Grid.

Handler​

A handler is a logic concept that overrides standard CRUD operations with custom behavior. A handler is best used for actions that need to be performed row-by-row, for example, to delete child records before deleting a parent record. For set-based actions, it is best to use triggers. See also Handler.

Indicium​

Indicium is the application-tier service of the Thinkwise Platform.

See also Indicium.

Indicium API​

The Indicium application tier provides the Indicium API. This an open, RESTful interface that enables external applications and tools to interact with your application using standard web protocols. It adheres to OData version 4.0 and is subject to IAM access controls. See also OData API.

Intelligent Application Manager (IAM)​

The Intelligent Application Manager (IAM) is the runtime administration layer of the Thinkwise Platform. It has multiple responsibilities:

  • Model synchronization hub: After you develop and refine application models in the Software Factory, you synchronize them to IAM. IAM stores and manages models across different stages. It ensures runtime components interpret the correct model with the right authorization and preferences.
  • Authorization and user personalization: IAM handles the assignment of user roles, preferences (such as themes, menus, and prefilters), and group memberships.
  • Personalized runtime behavior: Runtime components such as Indicium and the user interfaces combine the model as stored in IAM with the configured authorizations and preferences to deliver a custom experience per user.

See also Introduction to the Intelligent Application Manager.

Layout​

A layout is a logic concept that controls field visibility, modifiability, mandatory status, and button availability based on record values or context. See also Layout.

List bar menu​

A list bar menu is a menu-type screen component that supports a single level of menu groups and items. See also Menus.

Logic concept​

A logic concept is a specialized category of business logic that serves a distinct purpose. If your application needs functionality beyond what can be modeled directly, you can implement it using one or more logic concepts. Thinkwise supports the following logic concepts to extend your model:

See also Logic concepts.

Lookup​

A lookup is a user interface component that enables you to select or view values from a related (referenced) table. It allows customization of display values, interaction behavior, and configuration context. This includes options like auto-completion, dropdowns, suggestion filters, and pop-up displays. See also Lookups.

Manifest​

A manifest is a JSON or YAML configuration file that describes the structure of deployable products inside a deployment package for the Deployment Center. It includes the types of product contained in the package and the location of the files needed to deploy them. See also Manifest for the Deployment Center.

Maps​

A map is a screen component that is used to visualize locations or track assets from within your application. It provides third-party integration with various map providers to support base layers, overlay layers, and geocoding. See also Maps.

Metamodel​

The metamodel contains the structural definition and metadata that describe how application models are stored, interpreted, and managed. It includes definitions of objects that are used in a model, like templates, screen types, UI components, and more.

Meta control procedure​

A meta control procedure is a control procedure that is added to your model through dynamic modeling. If the specific functionality you need is not available in the Thinkstore and cannot be created in the Software Factory, you can extend your model by writing your own SQL meta control procedure. It adds functionality to your entire model based on specific conditions.

A meta control procedure is executed during every generation, and can be made responsible for the objects it maintains. If you only want to make a one-time adjustment to your model or its data, using an enrichment might be a better option. See also Dynamic modeling.

Meta Source​

The Meta Source is a configuration property that indicates which system holds the metamodel. It specifies whether the model is loaded from the Software Factory or IAM, and which RDBMS is used. It ensures that the system knows where to find the runtime definition.

Model​

A model, or application model, is the structured collection of metadata that defines your application. It encapsulates all components needed to generate the end product. This includes its data model, user interface, business logic, processes, enrichments, and branches. It is stored in the Software Factory repository, and it is version-controlled. Two types of models are supported by the Thinkwise Platform: base models and work models. See also Models and branches.

Model definition​

A model definition is a version of your application model that is generated during the creation phase. The application model is composed and extended using the defined generic concepts, and the platform-specific definition is created.

This model definition then serves as the basis for code generation after being validated. See also Generate definition.

Model version​

A model version is a snapshot of the state of a model at a given point in time. It includes all definitions that are part of the model. A model version can be used as the source for creating a branch or be the target for merging one. You can also compare different model versions to see what has been changed over time. See also Models and branches.

Module​

A module is a cluster of roles per functional part of the model that defines the application scope. You can use a module to define the boundaries of functional parts of a model, so that you can limit the available functionality of applications in IAM. See also Modules.

Object model extender​

The object model extender, or extender, is a mechanism designed to release GUI features ahead of their formal availability in the Software Factory and IAM. Developers can use extenders to temporarily unlock new GUI capabilities. Once the new features are officially supported, the extender becomes obsolete and is automatically removed. See also Introduction to Extenders.

Preferences​

Preferences are a persistent configuration of settings associated with a user, user group, or application. They define settings like locale, user interface presentation, default language, start objects, and more. Preferences are defined and managed in IAM. There are three levels of preferences:

  • User preferences define the settings for an individual user. A main administrator can set a preferences configuration for each specific user. IAM can analyze a user's way of working and suggest optimizations to their preferences that can be applied by the administrator. Users can override (some of) the default user preference settings in the user interface. See also User preferences(../upcycler).
  • User group preferences define the settings for a user group. Individual users can override (some of) the default user preference settings in the user interface. See also Group preferences.
  • Application preferences define the default settings for an application. They are set by the application administrator and can be overridden by individual user preferences. See also the sections about application settings under Create and application.

Prefilter​

A prefilter is a predefined filter applied to a subject, such as a table or view, that limits which records are displayed by default in the user interface. It can be based on specified column conditions or a custom SQL query. It offers configurable visibility and state behavior across different UI contexts. See also Prefilters.

Primary action​

A primary action, also referred to as 'Call to Action', is an action in the action bar that is highlighted on the screen. This can help establish a clear visual hierarchy in your application. By default, the Save action is marked as a primary action. You can configure an unlimited number of primary actions.

Windows GUI Tasks, reports, prefilters, cube views, and search cannot be configured as primary actions.

See also Configure the default Action bar settings.

Procedure​

A procedure is a type of subroutine that performs actions in a certain order. It is a snippet of reusable logic that can have input and output parameters. It can call one or multiple functions and can return no value, a scalar value, or a table. See also Introduction to subroutines.

Process​

A process is a logic concept that determines the next process actions in a process flow or system flow. It can use and influence process variables. See also Logic concepts.

Process action​

A process action (or process flow action) is a distinct step or operation within a process flow. It represents either a user-driven interface interaction or an automated system task. A process action has a set of input parameters (constants or variables) and output parameters (used to pass data to later actions in the flow). See also Add process actions.

Process flow​

A process flow is a structured sequence of process actions within an application, connected by process steps. With a process flow, you can guide data entry, handle approval procedures, and more.

A process flow consists of a starting point, one or more process actions connected by process steps, and a clear ending point. It can have one or more process variables to store data that persists throughout the process flow's runtime. Each process action can lead to different next steps based on success or failure conditions. A process flow can be reused in other process flows as a subflow to avoid duplicating common processes.

A process flow that operates without user interaction is called a system flow. See also Create a process flow.

screenshot: The structure of a process flow

The structure of a process flow

Process step​

A process step links two process actions in a process flow. It defines which process action is executed next based on the outcome of the preceding process action. A process step can be configured to execute under specific conditions:

  • If the previous action was successful.
  • If the previous action was not successful.
  • Always follow this path regardless of outcome.

See also Add process steps.

screenshot: Process steps in a process flow

Process steps in a process flow

Process variable​

A process variable is a named element in a process flow that persists throughout the flow's lifetime. You can use it to hold values produced by process actions (via output parameters) or to pass data into process actions (via input parameters). Process variables make dynamic, conditional workflows possible. See also Add process variables.

Program object item​

A program object item is a distinct part of a program object that encapsulates executable business logic. Some program object items, like headers and footers, are automatically generated by the Software Factory. Other program object items are inserted via your own templates containing business logic. See also Program objects and items.

Program object​

A program object is a generated element in the final application, such as a stored procedure, trigger, or function. It consists of one or more program object items. It is created by the Software Factory based on your control procedures and logic templates. See also Program objects and items.

Quick launch toolbar​

Windows GUI The quick launch toolbar is a navigation UI component in the Windows GUI. It provides quick access to different parts of the application such as work screens, tasks, and reports. The items in the quick launch toolbar are grouped logically. See also Quick launch toolbar.

Reciprocal merge​

A reciprocal merge is a merging technique where you merge the changes in your branch back into the origin and vice versa. After this, you keep working in your branch. With a reciprocal merge, you not only make the changes in your branch available in the origin, you also ensure that you can use anything new that has been merged into the origin branch since you created your branch. See also Introduction to merging.

Report​

A report enables you to generate and present data in various formats such as printed documents, previews, or exports. It can be created with a reporting tool such as DevExpress Reports, Crystal Reports, i-net Clear Reports, SQL Server Reporting Services (SSRS), or Word. It has a structure similar to tasks, where parameters are defined for a report, and references provide lookup functionality.

See also Reports.

Report bar​

A report bar is a screen component that shows a button for each report. If there are no reports, the report bar is hidden automatically. You can also add a report bar to the action bar. See also Report bar.

Runtime configuration​

A runtime configuration specifies the runtime environment in which your application launches. It includes details such as the database server, database name, and other environment-specific settings. By defining multiple runtime configurations, you can run the same application in different environments, such as development, testing, acceptance, and production. You can customize settings like OAuth servers, email providers, file storage locations, etc. on the runtime configuration level. See also Runtime configurations.

Scheduler​

A scheduler is a screen component that is used to visualize appointments or tasks on a timeline. It allows applications to present scheduled activities in a time-based, visual format, and for users to interact with them. See also Schedulers.

Screen area​

A screen area is group of similar information within a screen type that enables you to organize different UI components into distinct regions on the screen. You can use it to control where each component appears within the layout.

If a screen component is associated with a screen area that is not present in the assigned screen type, it is automatically added to the designated fallback area. This ensures that screen components remain visible even if their intended screen area does not exist. See also Screen areas.

Screen component​

A screen component is an individual, configurable UI building block that you place within a screen type to construct the user interface layout for a given subject. Common screen components are grids, forms, cardlists, bar components, and more. Components define how data and actions are displayed and interacted with in the application. Each screen component has its own configurable properties and can be positioned within designated screen areas of the screen layout. See also Universal screen components.

Screen type​

A screen type determines how a subject is visualized in various contexts. The different levels for which a screen type can be specified are main screen, detail screen, pop-up screen, and zoomed screen. For each of these levels, you can define which components are shown and where. A screen type is a generic definition of a layout structure, and you can assign it to multiple subjects. See also Screen type design.

Security check​

A security check is a feature in IAM that tests and confirms whether only the allowed data is accessible for a given user (group). See also Security checks.

Snapshot​

DB2 Oracle A snapshot is a data model object similar to a view, but with a key difference: its results are physically stored in a table rather than computed on the fly. This improves performance, especially for queries that would otherwise request large datasets repeatedly. The results may be out-of-date since they are not updated live. See also Add a snapshot.

Software Factory​

The Software Factory is a core component of the Thinkwise Platform. In the Software Factory, you can model, develop, and test your application without writing any code. You can define your application's structure, behavior, and user interface using model-driven tooling to create a logical model. Because it is model-driven, you can demonstrate a working prototype of your application immediately after modeling. See also Introduction to the Software Factory.

Specification​

A specification represents the documented requirements that form the basis of your data model and overall application functionality. It includes business processes, system behaviors, feature trees, iterations, and work items. In essence, it is an integrated, model-driven representation of your application's scope, required behavior, and development roadmap. It enables clear alignment with stakeholders, tracking, and structured evolution over the application lifecycle.

Start object​

A start object is a screen, task, report, or process that is automatically loaded during start-up. Start objects are added in IAM, either for a user or for an entire user group. An administrator can also run an automatic analysis of the user's behavior and preferences and apply its recommendations to set the most useful start objects for that user. Users can also create their own start objects in their user preferences. See also Add start objects for a user.

Starting point​

A starting point is the process action that initiates the execution of a process flow. A process flow can be triggered by user interaction or it can be triggered via the Indicium API.

When setting up a process flow, you can define which specific action(s) can serve as valid triggers for the process flow. Via the GUI, only certain actions are allowed to serve as starting points for user-triggered process flows. However, every process action can be invoked programmatically from external systems via the Indicium API. See also Starting points.

Stored procedure​

A stored procedure is a type of program object generated by the Software Factory. It is based on control procedures and templates. It serves as an executable logic component within your database layer, just like triggers and functions. A stored procedure includes a system-generated header and footer and one or more program object items that are inserted via templates. See also Subroutines.

Subflow​

A subflow is a reusable (segment of a) system flow that can be used to execute a common sequence of process actions. A process flow can call a subflow to execute part of its workflow. A subflow can return the values of process variables to the process flow that called it.

Subflows allow you to avoid duplicating logic across multiple process flows. They also keep your designs cleaner and more maintainable. See also Subflows in a process flow.

Subject​

A subject is a model element that defines how a specific data source (table, snapshot (DB2 and Oracle), or view) is presented and configured within the user interface. Each subject lets you configure the following and more:

See also Introduction to Subjects.

Subname​

A subname is a building block used to construct consistent and clear names for model objects such as tables, columns, references, and other elements within the Software Factory. It ensures that developers use the same naming patterns and terms consistently across the entire model. By composing object names from approved subnames, you avoid typos, inconsistencies, or ambiguous terminology. Validations verify that the proper naming is used.

Subnames can be grouped into subname groups. A subname group is a collection of the approved and disapproved subnames that apply to a specific model or branch to ensure consistent naming across your project. You can maintain and manage these groups to centralize and enforce naming standards. See also Introduction to subnames and Subname groups.

Subroutine​

A subroutine is a reusable piece of logic, with or without parameters, that encapsulates a specific operation. It can be called from other parts of the application. Subroutines can be of different types:

A subroutine is generally internal to the application. However, it can also be exposed as a service via the API, so that it can be called externally.

Subroutines can be configured to run as atomic transactions. When enabled, all changes made within the subroutine are committed only if it completes successfully; otherwise, changes are rolled back. Nested transaction support is also available for subroutines called within other subroutines. See also Subroutines.

Synchronization (to IAM)​

Synchronization to IAM is the process of deploying your application's model from the Software Factory to the Intelligent Application Manager. Synchronization is performed by Indicium as a background process. It can be automated using the Indicium API. Once your application model has been synchronized to IAM, it is available to the runtime environment. See also Synchronization to IAM.

System flow​

A system flow is an automated process flow that operates without requiring direct user input. Unlike standard process flows that start via user-triggered actions, system flows are designed to run in the background. They are often triggered on a schedule or by system events. System flows are well-suited for use cases like data synchronization, nightly maintenance jobs, periodic integrations, or cleanup operations. See also Create a system flow.

System flow schedule​

A system flow schedule, or process schedule, can be used to schedule the execution of system flows in your applications. This process schedule is created in the Software Factory and can also be managed in IAM, depending on its settings. Thinkwise supplies predefined system flow schedules, for example, to perform regular system cleanups, run security scans, etc. You can also create your own custom system flow schedules. See also System flow schedules.

Tab container​

A tab container is a screen component used within a screen type to organize content into multiple tabs. Each tab can host its own set of components. With tab containers, you can create structured grouping of data and data interaction within the user interface. See also Tab container component.

Table report​

A table report is a predefined type of report linked to one or more tables. It is displayed in the table's report bar or action bar. You can execute a table report in various locations in the context of its linked table(s), such as the ribbon and the context menu. Table columns can be tied to report parameters. This allows the active record's column values to be passed as input when the report is run. See also Table reports.

Table task​

A table task is task that is linked directly to one or more tables within the application model. It is displayed in the table's task bar or action bar. You can also execute a table task in various locations in the context of its linked table(s), such as the ribbon and the context menu. Table columns can be tied to task parameters. This allows the active record's column values to be passed as input when the task is run. See also Table tasks.

Task​

A task is a logic concept that manages standalone operations initiated by users or scheduled in batch processes. It represents a custom action such as running a procedure, executing a command, or triggering custom logic. It can be linked to one or more tables or subjects in the application model. A task can be the starting point for executing a process flow. See also Tasks.

Task bar​

A task bar is a screen component that shows a button for each task. If there are no tasks, the task bar is hidden automatically. You can also add a task bar to the action bar. See also Task bar.

Template​

A template is a code snippet that contains the business logic to fulfill a control procedure. It contains T-SQL code that defines what the control procedure should do. A control procedure can contain multiple templates. Assigning a template to one or more program objects is called weaving. See also Templates.

Thinkstore​

The Thinkstore is a curated repository of ready-made solutions such as templates, scripts, and sample models. They can be directly downloaded and installed into your models using the Software Factory. Using these reusable, proven components can accelerate development and reduce setup time and repetition. See also Thinkstore introduction.

Thinkwise Platform​

The Thinkwise Platform is an integrated software development environment. It is designed for building and modernizing enterprise applications using a model-driven, low-code approach. It provides a full stack, enabling streamlined application delivery.

The Thinkwise Platform consists of the following primary components:

See also the Thinkwise Platform Overview.

Tile​

A tile is a user interface element that presents items like a task, report, menu item, or related subject entry as a clickable tile.

Tiles menu​

A tiles menu is a menu-type screen component that displays items as large tiles or icons rather than a list or tree. Items are organized into groups, but can only have one nesting level. See also Menus.

Tree view menu​

A tree view menu is a menu-type screen component that displays menu groups and items hierarchically. The items and menus can be nested to any depth. See also Menus.

Trace fields​

Trace fields are added to all objects to track when a row was added or modified last and by whom. They are visible in a separate Trace info tab in every object. See also Use trace fields.

Translation object​

A translation object is a model element that stores the translations for any translatable object such as tables, columns, and tasks. In a translation object, you can add translations to multiple languages. You can also enter attributes depending on the object type, such as single/plural translations, tooltip text, and more. A translation object is automatically created whenever a translatable object is added or copied. See also Translation objects.

Trigger​

A trigger is a logic concept that executes on insert, update, or delete actions. With a trigger, actions can be performed as a result of (attempted) changes in data. A trigger can also prevent or undo changes in data. It can execute logic before, after, or instead of the database operation. A trigger is best used for set-based actions. For row-by-row actions, it is best to use handlers. See also Trigger/event.

Universal GUI​

The Universal GUI is a modern, responsive user interface that has been designed for mobile, desktop, and web platforms. It is distinct from the desktop-style Windows GUI. It operates as a Progressive Web App (PWA) built with React, and supports Material Design styling and dynamic theming. The Universal GUI only retrieves the parts of the application model needed at any given moment, which ensures fast startup times. It delivers a unified experience across devices while connecting with the Indicium application tier for runtime logic and data handling. See also Introduction to the Universal user interface.

Upcycler​

The Upcycler is a specialized tool that can automatically transform a legacy application into a modern Thinkwise-based application. It handles both metadata and data conversion, and generates a Thinkwise-compatible model. The data is automatically migrated to a new RDBMS of your choice. The Upcycler can use AI and other technologies to enrich your legacy application during the process. The resulting modernized application has a fully responsive web app user interface and an integrated service tier. See also Introduction to the Thinkwise Upcycler.

Validation​

A validation is a model integrity check that is performed to identify configuration errors, warnings, or other issues within your application model. There are automated, pre-defined checks available based on Thinkwise's base model, but you can also create custom validations to suit your needs. Validations are available in every modeling screen, so that you can instantly check and correct issues as you work on the application. Validation is also a phase during the Creation process. We recommend to resolve all validation issues before deployment. See also Validation.

Variant​

A variant allows the same data source (table, task, or report) to be presented in multiple ways. Each variant can have its own configuration, prefilters, screen layouts, and UI behavior. Using a variant means that the underlying model does not have to be duplicated. In a variant screen, a tab is available where you can see how it is different from the default. See also Variants.

View​

A view is a defined query in the data model that presents combined data from multiple tables at runtime. It does not store any rows physically. A view presents live data when the query is executed, which ensures that the information displayed is consistently up-to-date.

DB2 Oracle If you want to store the data, use a snapshot instead.

In the Software Factory, tables and views are treated identically when configuring subjects for the user interface. This means that you can apply UI logic, layout, and behavior to views just as you would with tables. See also Add a view.

Weaving​

Weaving is the process of assigning a templates to one or more program objects. This way, you can reuse logic and develop faster. You can assign a template in two ways:

  • Static: assign the template to each program object manually.
  • Dynamic: Use a SQL query to assign the template automatically to program objects based on a condition.

See also Assign the template.

Windows GUI​

The Windows GUI is the traditional, desktop-style client interface for Thinkwise applications. It is distinct from the web-based Universal GUI. The Windows GUI is deployed and launched as a native Windows application. It supports theme customization, allowing for configuration of colors, font, and tab styles. The Windows GUI becomes End of Life in 2026, so we recommend using the Universal GUI instead. See also Basics in the Windows user interface.

Work model​

A work model is a model that is intended for active development of an application. You build your specific application logic, UI, data model, features, etc. in a work model. A work model can inherit certain elements from one or more base models such as default translations, themes, and more. You can download some useful models from the Thinkstore. See also Set model details.

Work screen​

A work screen is the main interface where users interact with data and perform tasks within the application. It consists of a ribbon at the top, navigation support, content display components like grids and forms, and task/report interaction. If multiple screens are open, you can navigate between them via tabs at the top. The currently selected screen is the work screen. See also Work screen.

Was this article helpful?