For the complete documentation index, see llms.txt. This page is also available as Markdown.

Request availability control

Temporary lock mechanism allows you to control the availability of the application based on business configuration parameters. It can be used for business or technical reasons. When the lock is active, the user cannot start submitting the application and is redirected to a page with an unavailability message.

Examples of use:

  • Failures and critical errors - disabling the application when an error is found. This prevents customers from using a faulty process, and gives developers time to analyze and implement a fix before it is relaunched.

  • Technical and maintenance breaks - temporarily disabling the application due to planned unavailability of internal or external systems on which the application depends (e.g. service maintenance break on 12.08 from 21:00–00:00).

  • Periodic availability - limiting the ability to submit the application only to strictly defined time windows (e.g. time-limited deposits, government applications).

Availability control parameters of the application can be defined and edited in the Configuration tab in the application view in Eximee Designer. Details: Low-code configuration.

To change the parameter values at any time, without having to release a new version of the application, you can override them in the Application configuration tab in Eximee Dashboard. The operation is available to users with the appropriate permissions. More information: Modifying (runtime) business configurations.

Example configuration structure

The configuration is divided into three logical blocks, relating to the type of application unavailability:

  • global status - related to a sudden failure,

  • maintenance break - concerning a planned, time-bounded blocking of the process,

  • schedule - availability according to specific dates (and times).

# --- 1. GLOBAL STATUS (FAILURE) ---
form.globalStatus.isOutage=false
form.globalStatus.textContent=formUnavailabilityFailure-*

# --- 2. MAINTENANCE BREAK (MAINTENANCE) ---
form.maintenance.isScheduled=true
form.maintenance.startDate=2026-07-22T13:00:00
form.maintenance.endDate=2026-07-22T15:00:00
form.maintenance.textContent=formUnavailabilityMaintenance-*

# --- 3. SCHEDULE (SCHEDULE) ---
# Values: ALWAYS_AVAILABLE, EXACT_DATE_TIME, YEARLY_RECURRING
form.schedule.ruleType=YEARLY_RECURRING
form.schedule.textContent=formUnavailabilityScheduled-*

# For rule: EXACT_DATE_TIME
form.schedule.exact.startDateTime=2026-01-01T08:00:00
form.schedule.exact.endDateTime=2026-12-31T23:59:59

# For rule: YEARLY_RECURRING (MM-DD format)
form.schedule.recurring.startMonthDay=07-01
form.schedule.recurring.endMonthDay=11-30

Validation rules and priorities

The mechanism operates on a cascading architecture. It checks conditions from the most critical to the most general. Meeting a blocking condition causes form processing to be interrupted and the user to be shown the appropriate unavailability message.

Parameter
Format / Values
Description

form.globalStatus.isOutage

true / false

Priority 1: Immediate blocking of the application, ignores the remaining settings.

form.maintenance.isScheduled

true / false

Priority 2: Blocking the application within the defined maintenance break time window.

form.schedule.ruleType

ALWAYS_AVAILABLE EXACT_DATE_TIME YEARLY_RECURRING

Priority 3: Schedule rule checked when there is no failure or maintenance break.

form.*.textContent

artifact name (in the format artifactName-version)

The content of the appropriate error message displayed to the user. The notation artifactName-* means the latest available version of the artifact with the given name.

form.maintenance.startDate / endDate

date and time (in the format YYYY-MM-DDTHH:MM:SS)

Start and end of the planned maintenance break.

form.schedule.exact.startDateTime / endDateTime

date and time (in the format YYYY-MM-DDTHH:MM:SS)

Start and end of the strict, one-time schedule of application availability.

form.schedule.recurring.startMonthDay / endMonthDay

date (in the format MM-DD)

Month and day of the start and end of the recurring application availability.

If no condition is met, the script finishes without an error, which the system interprets as full availability of the application.

Configuration for individual environments

Configuration parameters can take different values depending on the environment. This is useful, for example, when the application should be blocked in the production environment, but still available in development and test environments to allow it to be run and verified by low-code developers and testers.

For example, the global lock parameter may have the value true only in the production environment:

The values of the availability control parameters should be assigned to the appropriate environments. The way the environment is marked in the configuration key and the rules for selecting values are described on the page: Low-code configuration.

Example script controlling application availability

The script verifies whether the client can open the application form, based on the declared configuration. Validation is based on a cascading (priority) structure, where meeting one of the blocking conditions immediately interrupts processing and displays the appropriate error screen.

The method getOrDefault()was used to retrieve configuration parameters. If the specified key does not exist, the method returns the default value defined in the script.

A good practice is to use the method .msg when invoking a business error. A clear business message should be passed there - e.g. .msg("Application unavailable"). The defined message will be written to the logs, which will make it easier to analyze and identify errors. More information about business errors: Error pages.

To ensure the proper operation of the mechanism, the described script should be attached to the application as EntryService (Properties tab).

Figure 1. Attaching the script as the application entry service

Usage examples (Business scenarios)

Business situation
Configuration
Result

Sudden database error

  • form.globalStatus.isOutage=true

  • Other parameters unchanged

The application becomes unavailable immediately.

Deployment of a new version scheduled for the weekend

  • form.maintenance.isScheduled=true

  • form.maintenance.startDate=2026-07-22T13:00:00

  • form.maintenance.endDate=2026-07-22T15:00:00

The application will be unavailable during the indicated period, and once it ends it will be automatically made available again.

Recurring availability of the “Good Start” program (300+)

  • form.schedule.ruleType=YEARLY_RECURRING

  • form.schedule.recurring.startMonthDay=07-01

  • form.schedule.recurring.endMonthDay=11-30

The application will be available every year during the indicated period.

Standard application with no time restrictions

  • form.schedule.ruleType=ALWAYS_AVAILABLE

  • form.globalStatus.isOutage=false

  • form.maintenance.isScheduled=false

Application available without restrictions.

Examples of unavailability messages

In electronic and mobile banking, word choice in messages (so-called UX writing) directly affects the sense of security and customer trust. In Eximee Designer, the content of the displayed message is defined in the artifact Formatted content (TextContent) specified in the configuration of the appropriate lock type.

Application availability every year on a specific date

The message should inform the user during which period the application is available and encourage them to use it again at that time.

  • Title: The application will be available from July 1

  • Content: You can submit this application from July 1 to November 30. Please come back during this period.

Figure 2. Example of a schedule-based application unavailability message

Failure (“We’re working on it”)

The message should briefly explain the situation, inform the user about the ongoing work to resolve the problem, and indicate what they should do next. Do not include technical details or error codes.

  • Title: The application is temporarily unavailable

  • Content: Sorry, we are experiencing technical difficulties. Submitting the application is currently impossible. We are aware of the problem and are working to resolve it. Please try again later.

Figure 3. Example of an application unavailability message due to a failure

Maintenance break

The content of the message during the maintenance break should clearly state when the application will be available again.

  • Title: Maintenance work in progress

  • Content: This application is unavailable due to planned maintenance work. The work will last until 16:00. We apologize for the inconvenience and invite you to come back after that time.

Figure 4. Example of an application unavailability message due to a maintenance break

Demo application: demoFormUnavailability_app

Download the file and import it into Eximee Designer to run the application in your environment.

Last updated

Was this helpful?