Skip to main content

Cases and casetypes

Cases are a fundamental part of Grexx Platform. Every object or process in your application is represented by a case. A case can refer to:

  • Things, such as a product, a person, an invoice, or a concept.
  • Processes, such as placing an order or booking a flight.
  • Users of your application.
  • Pages in your application, such as the homepage or a report.
  • More complex pieces of functionality that are encapsulated as a system service case.

The characteristics of a case and the things you can do with a case are all defined by its casetype. Each case in your system is an instance of a casetype. For example, in the HR system you create during the Studio tutorial, each employee is a case and belongs to the Employee casetype.

You can think of a casetype as the blueprint for the individual cases. Among other things, the casetype defines:

  • The data that is associated with each case - such as the employee's name and contact details.
  • The things that can be done to the case - such as updating an employee's personal details or booking their annual leave.
  • The GUI for viewing and interacting with cases - such as an individual employee's page with a grid listing the devices assigned to them, and the form for editing an employee's details.
Tip:

You define casetypes from your Grexx Studio, but you create the individual cases (the instances of each casetype) in the application. This means cases are specific to an environment: Development, Testing, Acceptance or Production.

Features of casetypes​

While casetypes can represent a wide range of things and processes, they are all defined using a common set of features.

Attributes​

Attributes define the characteristics that can be recorded for each case of that type. For example, an Employee casetype might include attributes to record each individual's name, email address, date of birth and start date.

For information about adding attributes to casetypes, see Create casetypes. For information about attribute options, see the Attributes reference.

Forms​

Forms define the GUI for adding or editing the attributes of individual cases. You can create activities to give your users access to forms so that they can add data to a case or edit existing values.

For information about using forms in your application, see Design forms.

Activities​

Activities define what users can do in relation to a case. For example, you can add an activity to enable users to edit the attributes of an existing case using a form.

You can also use activities to create a case of another casetype. For example, in the Studio tutorial, you added an activity to the Employee casetype to add an entry to the personnel file. Each time the activity is performed, a new personnel file case is created.

As well as performing activities manually, you can add logic to automate specific steps, such as populating attributes on the case created by the activity. For example, in the case of the personnel file, you added logic to populate the Employee attribute with the case ID of the employee case.

For more information about the role of activities in Grexx Platform, see Activities and tasks. For information about adding activities to your application, see Define casetypes and activities and the associated guides.

Views​

Views define the GUI that displays the details of each case. By default, each casetype includes a Main view, which defines the layout and contents of the webpage for cases of that type.

You can also define other views for use either as standalone pages in your application or embedded within another page.

For information about adding views to your application, see Configure pages and views.

Roles​

Roles identify users and are used to grant those users rights to perform individual activities, view data displayed in views, and navigate around your application. This gives you fine-grained role-based access control (RBAC) throughout your application.

For information about granting users permissions in your application, see Manage users and permissions.

Audit trail​

In Grexx Platform, every case and casetype includes a complete audit trail of the changes that have been made to it and the author of those changes.

You can view the audit trail for each casetype from your Grexx Studio. This includes information such as when attributes were created or activities were modified.

You can view the audit trail for individual cases using Developer Tools in the relevant environment (Development, Testing. Acceptance or Production). This includes information such as when an attribute was populated or an activity was performed. For information about using Developer Tools, see Debug your application.

Unique ID​

Every case is created with an identifier that is unique across all Grexx environments. This makes it easy to find and execute activities on a specific case - both manually through your application's UI and programmatically from another system by calling the Grexx API.

Case status and lifecycle​

Depending on the use case, you may want to close individual cases. For example, if you have a casetype that represents customer orders, you may want to close each case once the order has been dispatched. Similarly, for a casetype that represents the employee review process, you may want to close each case once the review process has been completed.

When you close a case, it remains available in the system and can be reopened using an activity. You can also trigger other activities when a case is closed. For information about configuring activities to close cases, see Close cases.

Interactions between casetypes​

One of the benefits of representing every process and thing as a case is that you can reuse functionality in different parts of your system.

You saw an example of this in the Studio tutorial: you initiated the default Invite user casetype from an activity on the Employee casetype so that you could give employees access to the application. The Invite user casetype defines all the functionality required to add a user to the system. When it is called, a new Invite user case is created, which in turn creates a new User case.

If you wanted to add functionality to create users that were not first added as employees (for example, to give an external auditor read-only access to the system), you could re-use the Invite user casetype in a different context. For example, you could initiate it from an activity on a User management page casetype.

Being able to reuse functionality not only saves time when building new features but also means there is only one set of logic to maintain and debug if something does not behave as expected. The universality of casetypes also makes it easy to share functionality between different applications - either within your own organization or via the Grexx Marketplace.

Next steps​

Before starting to develop your application with Grexx Platform, it is worth taking the time to consider the casetypes you will need to use and how they will interact with each other via activities. We discuss this further in Design your application.