Updated 7 months ago by Mobsted Support L


As we already mentioned, one of the three main components of the Mobsted platform is the Backend. Backend is where all the events are stored in the system. Sometimes the events are pretty basic like submitting the age entered, and sometimes they're more complex for example: the Event of submitting the issue of some kind.

While the event of submitting the age doesn't require any specific manipulations with it, the event of submitting the issue might involve different participants and different states.
When the event of the issue existing is created, the Servicer receives the notification regarding it. it is logical that the servicer would contact the responsible person to fix the issue and when the issue is fixed the Servicer might want to update the AppUser that the Issue is closed.

The above example might be divided into three logical parts:

  1. Issue is received
  2. Issue is in the process of resolution
  3. Issue is resolved (closed)

That's when statuses come into play. Each logical part would be represented as a separate statuses:

  1. Open
  2. Processing
  3. Closed

The Mobsted platform allows you assign statuses to each Event and track the execution of it.


In order to find the status go to the Constructor from the Home Screen of the Mobsted platform first. Once you're in a Constructor, mouse overing the backend would show you the menu where one of the options would be statuses. Please take a look at the gif that illustrates the path to the statuses.


Once you're in the Statuses section you can see that you have two statuses pre-created for you: Open Status and Closed Status. But the above example shows there are a bunch of cases where we would need more than two statuses. So let's customize the current ones add a status.

If you click on any existing status you can see some fields in there that would help you to customize your status.

  1. Status Name: the name of the status that Servicers would see. Give it a meaningful but short name so Servicer could easily read and catch.
  2. Who can use: The option to choose whom the status would be visible to. It might be visible only for the servicers(SM), or only for the AppUsers (MU), or both.
  3. Font Color and Background Color: the status styling elements. We would suggest to the meaningful backend color, for example if the status is open you can use red color, if the Event is in processing then it's good idea to use yellow, and if the Event is closed - green.


To change the status of the event you can change the status of the event in the backend. Please navigate to the Backend section for more info.

Was it useful?