Skip to main content

Design your application

Building your own application with Grexx Platform gives you the freedom to create a custom solution that meets your specific requirements. From customizing existing workflows to creating new software systems, you can use Grexx to create applications to meet a wide range of business needs. What's more, as a low-code solution, Grexx Platform is ideal for non-developers - all you need is a good understanding of your business and its processes.

This article provides guidance on the things to consider before you start building an application and advice on how to manage your project.

Tip:

Before you start designing your application, we recommend that you complete the interactive tutorial. The tutorial provides a practical introduction to key concepts in Grexx while walking you through the process of building a simple application.

Define the problem​

You probably already have a specific use case for your application in mind. Perhaps your organization is using one or more off-the-shelf software products to manage customer data or process orders, but you still have to perform a number of steps manually. Or maybe you want to replace a legacy system with a web-based solution that you can easily update as your business evolves.

Whatever your use case, we recommend that you start by taking a step back to consider the wider business goals that you're trying to achieve with your existing process, rather than simply building an application that replicates the existing steps.

For example, if you're building an application to manage employee expense claims, your business goal could be to ensure that expenses are legitimate and paid out in a timely manner. The existing manual process may involve each claim being checked by someone in the finance team to match it to the appropriate expense category. However, it's possible you could meet the business objective more efficiently by asking employees to select the correct expense category and only requiring claims to be checked manually if they exceed a certain value.

Looking at the big picture in this way can help you to identify opportunities to use software to make your business processes more reliable, efficient and effective. Digitalizing your processes can also give your business more flexibility to innovate and respond to changing market demands. By taking the time to consider your organization's strategy and goals, you can ensure that the applications you build with Grexx Platform support your business in the long term.

You may find some or all of the following techniques helpful when exploring and defining the business problem:

Model the current approach and future solution​

Once you have clarified the problem you want to solve, we recommend that you spend some time modelling both the current approach and potential solutions. Drawing up models of the business domain, processes, data and people involved will help you to:

  • Clarify the design of your application.
  • Engage stakeholders in the solution and speed up adoption of new ways of working.
  • Scope the project and break it down into manageable chunks.
  • Document your plans so that you have something to refer back to in future.

Domain model​

A domain model identifies the different parts of your business, existing systems and any external actors that are involved in the problem space. For example, the domain model for an online floristry business might encompass growers, delivery companies and customers, as well as online marketing platforms, accountancy tools and the floristry staff themselves. Each of these elements is involved in reaching the business goal of supplying floral arrangements to customers without a physical shop.

Domains may be structured hierarchically, horizontally, or around a network of connections. The key is to map out all the entities involved and how they relate to each other. You can choose to use a formal domain modelling language or simply draw a representation of the domain on paper or using tools such as Microsoft PowerPoint or Visio. Include both existing systems that you expect to replace and any other systems that your Grexx application will need to integrate with.

Once you have mapped the domain, you can use your domain model to facilitate discussions with your stakeholders, find opportunities to improve existing processes, and prioritize the areas you want to address first. If you have identified external systems that you want to integrate with, check the Grexx Marketplace to see if a plugin is already available. If a plugin is not currently available, your Grexx Coach can advise you on how to proceed.

Application model​

You can use Grexx Platform to create a single application used by your business, or to make the same application available to multiple organizations. It's helpful to identify the appropriate application model early on as this will affect other aspects of the application design. Depending on your use case, there are four main ways in which you can set up an application on Grexx Platform:

  • Single tenant model: The simplest and most common approach is to build a single application for use within your organization. In a single tenant model:
    • All changes are made from the same Grexx Studio.
    • All users log in to the same instance of the application in Production.
  • Multi-tenant model: This model is suitable if you want to give multiple customers access to the same application. In a multi-tenant model:
    • All changes are made from the same Grexx Studio.
    • All users log in to the same instance of the application in Production.
    • Cases and roles must be designed to ensure separation of customer data. For example, you might use a Customer ID attribute to identify the customer that a user belongs to.
  • Network model: If you have several different types of customer and you want them to log in to the same application so that they can interact with each other, a network model may be appropriate. In a network model:
    • All changes are made from the same Grexx Studio.
    • All users log in to the same instance of the application in Production.
    • Cases and roles must be designed to enable different functionality for different customer types and to ensure separation of customer data. For example, instead of a Customer ID attribute, you might create attributes to identify the different types of customer (such as Buyer ID, Seller ID and Agent ID).
  • Connected platform model: If you have multiple customers and want to give each one their own dedicated application, you will need multiple instances of the application in Production. In a connected platform model:
    • Changes are either managed from a central Grexx Studio and deployed to each customer's Production environment, or changes have to be replicated across multiple Studios, each with its own set of Development, Testing, Acceptance and Production environments.
    • Each customer has their own instance of the application in Production and their users log in to that customer-specific application. This ensures complete separation of customer data.
    • Cases and roles should be designed to make different features available to different types of user within each application (such as buyers versus sellers).

Casetype model​

Cases and casetypes are the fundamental building blocks of any applications you create on Grexx Platform.

Casetypes define the things and processes that your application manages. This includes things such as customers, employees, products, or assets, and processes such as sending an email, dispatching an order, or granting a permit.

Cases are the specific things or processes themselves, such as customer A or sending an email to supplier X on 1 March 2024. Each case is an instance of a casetype (such as the Customer casetype or the Send email casetype), and each case is specific to the application environment in which it is created (Development, Testing, Acceptance or Production). For more information, see Cases and casetypes.

When identifying the casetypes that you will need for your application, consider both the initial problem you want to solve and how you expect to extend your application in future. Your aim is to strike a balance between creating casetypes that meet your specific needs and reusing logic where possible.

For example, if you have two similar things for which you want to collect the same data and perform the same activities, it usually makes sense to create a generic casetype (such as a casetype called Company rather than both Customer and Employer). However, if the activities you will perform on the two things are different, it usually makes sense to create separate casetypes.

Tip:

We recommend revisiting your casetype model once you have modelled the processes, data and permissions. It often takes several iterations to get your first set of casetypes right.

Process model​

A process model maps out all the steps, decisions and possible outcomes of a particular process. Drawing up a process as a flow diagram can help to facilitate conversations about the design of your application. You may want to map both the "as is" (i.e. current) process and the "to be" (i.e. future) process so you can easily compare the two.

Modelling the process gives you an opportunity to consider which steps you will automate with your application, as well as the inputs required. Where possible, make the parameters for rules adjustable and identify who will have responsibility for setting each rule. For example, if you want to set a threshold below which expense claims are automatically granted, consider who will have authority to set that threshold.

You can create process models using tools such as Microsoft Visio or Camunda. Add swimlanes to the process flow to identify the roles responsible for each step.

Tip:

If a process involves multiple exceptions or edge cases, consider handling these with a manual review step, rather than trying to define logic to handle every possible situation automatically. Once you have addressed the main use case, you can always revisit these edge cases and prioritize implementing logic for those that will add the most value.

Data model​

A data model defines the data that will be stored for each casetype and the relationships between casetypes. For each casetype, start by identifying the attributes you want to record and the type of data that each attribute will store (for example, a date, a number, some text, or an uploaded file). For each attribute, you can specify whether multiple values are permitted and define additional options such as the default value, validation rules, help text, and anonymization and data retention settings. For more information, see Cases and casetypes.

You can reference one case from another using the Case ID data type. For example, if you have an Order casetype, you might store the case ID of the customer that placed the order in a Customer attribute on the Order casetype. This is preferable to relying on the parent case from the case metadata of each Order case, as it makes it much easier to change the related case if required.

Once you have defined the attributes for your initial casetypes, look for any that are very similar across casetypes. You can set these up as platform attributes and configure the options centrally, before varying them per casetype as required. This is particularly useful for attributes such as bank account numbers or phone numbers.

Note:

It's important to identify any attributes that can have more than one value during this design phase, as it can be difficult to convert single attributes to support multiple values (or vice versa) later.

Permissions model​

A permissions model identifies who should have permission to view specific pieces of data and perform particular activities. If you included swimlanes in your process model, this will provide a good starting point to identify who should have access to what.

User permissions in Grexx Platform are based on the the principle of least privilege. This means that users are given as few permissions as possible by default, and that access to view data or perform actions must be explicitly granted.

When drawing up the permissions model for your application, consider whether you want to grant users access to all cases of a particular type (for example, to view all employees or edit all claims) or whether you only want to give them permission to view data or perform activities on a subset of those cases (perhaps only those employees in their department or only claims they have created themselves).

Plan and manage your project​

Our experience (in line with the software development industry generally) is that an iterative approach is much more effective than trying to create a detailed plan for building a complete application up front. This is partly because there are too many unknowns at the start of any project to plan it accurately, and partly because an iterative approach allows you to keep adapting to a changing context and incorporating feedback as you go.

For these reasons, we recommend taking an iterative approach when building applications with Grexx Platform. Start by implementing a small piece of functionality, testing it and making it available to at least some of your users. This allows you to validate your approach and collect feedback while solving at least part of a problem with working software. You can then use the insights you gain from this process to refine the implementation and inform future pieces of work.

Step 1: Create a backlog of things to do​

When working iteratively, it's helpful to maintain a list or "backlog" of the things you want to add to your application or change in future. Most projects start with a high-level list of features - sometimes known as "epics" - such as displaying key data on a dashboard or having a means of managing application users. These epics are made up of many smaller features, and may also be dependent on other epics. For example, it's only possible to display data on a dashboard once that data has been recorded in some way.

Step 2: Break backlog items into smaller tasks​

The next step is to break these epics down into their component features so you can prioritize them and manage any dependencies. You can then take the highest priority items in this list and break them down further into individual tasks or "user stories". The intention is for each task or user story to deliver a working piece of functionality - such as being able to record a piece of data or make changes to existing data - so that you can deploy and test each one as it's completed. This allows you to deliver value to your users in small increments and gather feedback as you do so.

Step 3: Build functionality incrementally via sprints​

Working in "sprints" of between one and three weeks is a widely used and effective way of building software applications through iterative development. During each sprint, teams work on a set of items from the backlog with the aim of delivering one or more usable pieces of functionality. At the end of each sprint, the completed work is demonstrated to stakeholders and may also be deployed to users. Sprints provide a useful cadence for delivering functionality iteratively and collecting feedback frequently.

Step 4: Use feedback to update your plans​

One of the advantages of an iterative approach is that it provides opportunities to review and refine your plans. You can use the insights you gain from building new functionality, sharing it with stakeholders and testing it on users to break down and re-prioritize the items in your backlog. You can also update your plans to accommodate changes in your business. As you prepare the user stories you want to work on in the next few sprints, keep the long term goal in mind but do not invest time planning work for more than the next few sprints.

Scrum

Further resources​

There are plenty of online and printed resources on software project management methodologies and techniques. The following can be useful places to start:

You may also want to use a tool such as Jira, Trello or Asana to manage your backlog and sprints.

Next steps​

Once you are ready to start building your application on Grexx Platform, it's time to head to your Studio and start adding casetypes and creating pages. If you have not done so already, please contact us to request a dedicated environment for your project. The Guides section of this documentation takes you through the main steps involved in developing an application on Grexx Platform. You can also raise any questions during the weekly Q&A sessions or request 1:1 support from your Grexx coach.