Creating an Application Form Definition

Within the trellispark framework, applications are assigned to a user to give them an entry point to a business function with a set of related tasks.

An example Form Definition page for an Application is shown below:

Application form definition overview page, showing the form name, type, purpose, tabs, attached files, application category, and icon URL

The Form Type will be set to “Application” and each Application will need a unique Form Name that identifies what functionality will be provided. An Application may have a series of Tabs that will display on the page in the same way as a Concept.

The icon URL field is used to specify the icon to be used from font awesome. The base standard is using the light suite. An example of the icon could be a trash can, in which case the value should be fa-light fa-trash-can

Applications appear in the left hand navigation and are ordered by the sequence field then alphabetically. Applications within categories are also sorted this way. Application categories are below all non-categorized applications in the left navigation and are also sorted based on their sequence and then alphabetically.

The data model for an application will typically consist of child lists:

Application form definition data model tab, displaying the field definitions table

These child lists will show up within the application as a set of tables to allow the user to choose which records they will be working with, listing the various records that the user has access to. Multiple child lists can be added to each application and on the various tabs.

By default, a user who has been assigned to the Workspace’s Administration Group can see all the records within the workspace. If this is not the desired behaviour, then you can modify the T-SQL used to populate the list must restrict the user’s view based on any criteria. For example, you could:

  • create Teams and Groups to restrict access to records to users
  • create business rules so that users can only see records that match defined conditions
  • list recently updated records
  • list records in a defined state
  • add Search Criteria to the list to prefilter the records based on any set of parameters

Applications do not need Form Permissions as users are not allowed to Save or Delete the workspace data directly. This also means that data field types should not be created on Application forms.

Applications do not need state transition diagrams or a series of state transition workflow of their own as they are not discrete identities within the workspace.

Previous article: Using Concept Subforms

Updated on June 3, 2024

Was this article helpful?

Related Articles

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support