Contacts - Example application

This is an example of a Standard application type with Card style. Card style applications show record information in the list form as cards, rather than rows of data.

Review the subheadings below for information on the different application features. 

Subtables

Subtables are an abstracted form of a table which show a limited number of records and data items in the field of an application. This enables you to show specific information from another table that relates to a parent record, without showing all of the information from the referenced table. 

For example, this application uses a subtable to store emails and phone numbers in a subtable.

To see how this was configured, navigate to:

Learn more in Subtables.

Inline applications and application links

Application links enable users to open other applications, interactive reports, or dashboard pages from inside your application. Application links can appear as buttons or row actions, they can change the application that users see when they create or edit a record, or they can insert an inline application into the detail form of your application. 

Inline applications allow you to add a fully functioning application or report into the detail form.

For example, this application includes an inline application on the Addresses page of each contact record. The inline application stores its own records and information, and includes an API configuration that uses Google Maps to show the selected address. 

To see how this was configured, navigate to: 

Learn more in Inline applications.

Dependent list lookups

Dependent list lookups limit the values which a user can select in one field, based on the value selected in another field.

For example, this application uses dependent list lookups to control what values are shown in the Function field based on the value selected in the Contact Role field. 

To see how this is configured, navigate to:

Learn more in Control available list lookup values.

Event actions

Event actions initiate logic blocks when users interact with different parts of the application. This application has multiple event actions configured, such as:

• Form is Initialized: The logic block runs when a user opens the application in any application form except the list form. In this example, the RefEnableDisableDirectory logic block which enables and disables fields when the application's detail form is opened. 
• Field Value Changed: The logic block runs when a user changes the value in a defined field and then exits the field or hits enter. In this example, the RefHideShowDirectory logic block hides and shows different fields based on the value selected in the Contact Role field. 

To see how this was configured, navigate to:

Learn more in Logic blocks and event actions.

Automatic numbers

Automatic numbers are non-repeating, alphanumeric values attached to data items that need to increment automatically as records are created. Use automatic numbers when a data item record needs to be numbered automatically with a unique value. 

For example, this application uses automatic numbers to ensure that each contact record has a unique, system generated Contact ID number. Once the initial automatic number has been defined, the system ensures each record has a unique, incremented value. 

Automatic numbers require multiple steps to configure. To see how this was configured, navigate to:

Learn more in Automatic numbers.

Inline Addresses - Example application

This is an example of a Advanced List application type with Mini App style. Mini App style applications open in a floating window over top of the open application. This means when you interact with a Mini App, the original application work is not lost. You can launch mini apps from either the Navigation Menu, or through an application action.

Review the subheadings below for information on the different application features. 

Inline applications

Inline applications allow you to add a fully functioning application or report into the detail form of another application. 

For example, this application is an inline application included in the detail form of the example Contacts application. You can access it from the Addresses page of the Contacts application, but it stores its own records and information. Additionally, it includes an API configuration that uses Google Maps to show the entered address. 

Learn more in Inline applications.

Format definitions

Format definitions designate what information users should input into fields of type Name, Address, and Multi-Segment. A specific format can be defaulted into a field, or a dropdown menu with different format options can open when you select the field. Once a format is selected, a box opens with multiple input lines where you can enter the required information. 

For example, one format could require only the State and Country, while another format could require the Address Line, City, State, Postal Code, and Country. 

Learn more in Format fields.

Projects and Tasks - Example application

This is an example of a Relationship application type with Tree style. Relationship Tree applications display relationships in a hierarchy. In this style, child records are nested below parent records in a tree, and rows can be expanded to show the children for each parent. This style supports a relationship cardinality of one-to-one and one-to-many. This application uses a one-to-one relationship. This means a record can only belong to one parent, but it allows for nested structures under a single root node. 

This application is built over a join table. Join tables connect multiple tables that share related data, and uses fields from each table to identify overlapping values. The result is a joined table that can be viewed in a new application, and connects records based on the overlap.

Review the subheadings below for information on the different application features. 

Filtered table lookups

Filtered table lookups filter the number of results viewed in a table lookup field.

For example, this application uses a filtered table lookup in the RefContact_RefContactName field to search the Contacts application's records. The table lookup filters the records based on the Contact Role, and only shows records of type Customer in the field. 

To see how this was configured, navigate to

Learn more in Filtered table lookups.

Search applications

Search applications are mini apps connected to another application by a table lookup field. The table lookup field gets populated by either opening the search application and selecting a record, or typing into the field and selecting from a drop down list of typeahead results.

In this application, a search application is attached to the RefChildTaskDefinition_RefTaskName field which allows you to search the Project and Tasks list form for the task you want to assign as a child task. 

To see how this was configured, navigate to:

Learn more in Search actions and search applications and [link: 'NextbotActionsSearch'].

Projects and Tasks - Example application

This is an example of a Relationship application type with Tree style. Relationship Tree applications display relationships in a hierarchy. In this style, child records are nested below parent records in a tree, and rows can be expanded to show the children for each parent. This style supports a relationship cardinality of one-to-one and one-to-many. This application uses a one-to-one relationship. This means a record can only belong to one parent, but it allows for nested structures under a single root node. 

This application is built over a join table. Join tables connect multiple tables that share related data, and uses fields from each table to identify overlapping values. The result is a joined table that can be viewed in a new application, and connects records based on the overlap.

Review the subheadings below for information on the different application features. 

Filtered table lookups

Filtered table lookups filter the number of results viewed in a table lookup field.

For example, this application uses a filtered table lookup in the RefContact_RefContactName field to search the Contacts application's records. The table lookup filters the records based on the Contact Role, and only shows records of type Customer in the field. 

To see how this was configured, navigate to

Learn more in Filtered table lookups.

Search applications

Search applications are mini apps connected to another application by a table lookup field. The table lookup field gets populated by either opening the search application and selecting a record, or typing into the field and selecting from a drop down list of typeahead results.

In this application, a search application is attached to the RefChildTaskDefinition_RefTaskName field which allows you to search the Project and Tasks list form for the task you want to assign as a child task. 

To see how this was configured, navigate to:

Learn more in Search actions and search applications and [link: 'NextbotActionsSearch'].

Task Manager - Example application

This is an example of a Advanced List application type with Standard style. This application type allows users to edit records from the list form, and provides a header row for filtering. The detail form of this application has been disabled, which means the records only display in a list form. 

Workflow

Workflow enables you to define a string of tasks that are linked together to create a single, contained process. This ensures users navigate through the required steps of the process in order to reach completion. Some of the benefits of using workflow in a business process include:

• Streamlining internal processes.
• Reducing redundancies and errors.
• Tracking statuses in real time.

For example, this uses workflow to indicate record status, update related records, and to enable or disable fields based on the record's status. 

To see how this was configured, navigate to:

Learn more in Workflow Home and Configure workflow.

Filtered table lookups

Filtered table lookups filter the number of results viewed in a table lookup field.

For example, this application uses a filtered table lookup in the RefContact_RefContactName field to search the Contact application's records. It filters the records based on the contact role selected, and only shows records of type Employee in the field. 

To see how this was configured, navigate to:

Learn more in Filtered table lookups.

Application links

Application links enable users to open other applications, interactive reports, or dashboard pages from inside your application. Application links can appear as buttons or row actions, they can change the application that users see when they create or edit a record, or they can insert an inline application into the detail form of your application. 

For example, this application uses an application link on the RefContact_RefContactName field. Once an employee has been selected in the table lookup field, a link appears that enables users to navigate to that employee's record in the Contact application. 

To see how this was configured, navigate to:

Learn more in Application links.

Search applications

Search applications are mini apps connected to another application by a table lookup field. The table lookup field gets populated by either opening the search application and selecting a record, or typing into the field and selecting from a drop down list of typeahead results.

In this application, there are multiple search applications attached to fields. One example is the RefContact_RefContactName field which allows you to search the Contacts application for employee records.

To see how this was configured, navigate to:

Learn more in Search actions and search applications and [link: 'NextbotActionsSearch'].

Filtered table Lookups

Filtered table lookups filter the number of results viewed in a table lookup field.

For example, this application uses a filtered table lookup in the Customer field to search the Contacts application's records. The table lookup filters the records based on the Contact Role, and only shows records of type Employee in the field. 

To see how this was configured, navigate to:

Learn more in Filtered table lookups.

Expense Reports - Example application

This is an example of a Header Detail application type with Standard style. This application type connects detail records that have the same header information. Header Detail applications are a combination of one Header application and one or more Detail applications. They are useful for one-to-many relationships that use transactional information. 

Learn more in Header Detail application and Header Detail application configuration.

Workflow approvals and orchestration

Workflow orchestration changes one record's workflow state when a different record's workflow state changes. This could be defined between records in two different tables, or between records on the same table. 

For example, in this application workflow orchestration is used to submit the detail records when the header record is submitted. 

Approvals require an authorized user to accept or reject certain transactions before they can move forward in a business process. The approval requests are configured on selected workflow transitions to control when records can move from one workflow state to another. 

For example, in this application approval requests are sent to designated approvers when the detail records are submitted.

To see how this was configured, navigate to:

Learn more in Configure a workflow definition, Workflow orchestration, and Workflow approvals.

Application links

Application links enable users to open other applications, interactive reports, or dashboard pages from inside your application. Application links can appear as buttons or row actions, they can change the application that users see when they create or edit a record, or they can insert an inline application into the detail form of your application. 

For example, this application uses an application link on the RefProject_RefTaskName field. Once a project has been selected in the table lookup field, a link appears that enables users to navigate to that project's record in the Project and Tasks application. A logic block is used to hide and show the application link.

To see how this was configured, navigate to:

Learn more in Application links.

Control actions

Control actions hide or disable fields buttons. This includes standard system buttons like Save or Cancel, as well as custom buttons.

Event actions

Event actions initiate logic blocks when users interact with different parts of the application. 

In this application, the detail application has one event action configured that initiates on Row Added events. This means the RefSetExpenseReportDetailCurrency logic block is initiated and sets the currency in the RefCurrencyCodeDefault field to USD when a user selects the Add Row button. The RefCurrencyCodeDefault field is hidden on the application, but holds the currency code that is used in the field dependencies configuration. 

To see how this was configured, navigate to:

Learn more in Logic blocks and event actions.

Field dependencies

Field dependencies allow you to dictate what is shown in one field, based on a value in another field in the application. 

For example, the Amount field in the detail application has its currency code dictated by a default currency code field defined in the application, but hidden from view.

To see how this was configured, navigate to:

Learn more in Field Dependencies.

Filtered table lookups

Filtered table lookups filter the number of results viewed in a table lookup field.

For example, this application uses a filtered table lookup in the RefSupplier_RefContactName field to search the Contacts application's records. The table lookup filters the records based on the Contact Role, and only shows records of type Supplier in the field. 

To see how this was configured, navigate to

Learn more in Filtered table lookups.

Automatic formats

Automatic formats are used to format automatic numbers of type Text data items. Automatic numbers allow you to automatically increment a non-repeating, alphanumeric value assigned to a data item. Automatic formats can add prefixes or suffixes, specify upper or lowercase for text, or pad or truncate an automatic number.

Automatic numbers require multiple steps to configure. To see how this was configured, navigate to:

Learn more in Automatic Formats configuration.

Filter - Example dashboard card

The Filter dashboard card is built over a Standard application with Mini App style. 

Review the subheading below for information on the dashboard card's features. 

Common context

Common context enables you to populate fields or filters in one application based on a value published in another application. 

Common context has two components:

• Publishers—The field which dictates the values populated in the Subscribers. When a value is entered or published into a publishing field, it populates all the subscribing fields configured in the same scope. 
• Subscribers—The field which is populated by the publishing field value.

In this dashboard, the RefContact_RefContactName is the publisher, and the other two dashboard cards have fields which are subscribers. This means when an employee is entered into the filter card, the other two dashboard cards automatically show records related to that employee. 

To see how this was configured, navigate to:

Employee - Example dashboard card

The Employee dashboard card is built over a Standard application with Card style. Card style applications show record information in the list form as cards, rather than rows of data.

Application layouts

Application layouts create versions of an application with different field placements, style, and more. The application inherits the underlying business logic and actions of their parent application, but can be configured for different uses.

For example, this application layout simplified the user interface so that only one card is shown per row, and several fields were consolidated to a single-column row. 

Learn more in Application layouts.

Calendar - Example dashboard card

Calendars are useful in many different processes. For example:

• Resource scheduling—Using dashboard calendars to assign qualified resources, such as employees or machines, to events that need to be completed within a scheduled timeframe, such as projects or work orders. 
• Available and unavailable time—Using calendars set up with work hours and holidays to help estimate things like bank transfers. This time can lapse days, for example from 10:00pm—4:00am.

Learn more in Calendars and Resource scheduling.

Task Manager - Example dashboard card

The Task Manager dashboard card is built over a Advanced List application with Mini App style. 

Application layouts

Application layouts create versions of an application with different field placements, style, and more. The application inherits the underlying business logic and actions of their parent application, but can be configured for different uses.

For example, this application layout changed the application style to a Mini App so the dashboard card could be built over it.

 Learn more in Application layouts.