How to structure a process correctly in MasterBase®.

A process in MasterBase® is not just a list of steps that are executed. It is a logical, automated part that is intended to be part of a larger solution. That's why it's not enough to manage the WIzard; you have to learn to think in processes.

The structure of a good process

All processes in MasterBase® follow a modular structure composed of three blocks:

1. INIT (Start)
   Here you define the base data that the process needs to start: databases, key fields, credentials and others. This block should be clean, with only the essentials.
2. STEPS (Steps)
   They constitute the core of the process. Each step contains one or more tasks, such as searching records, saving data, sending messages, generating PDFs, among others.
   The steps are executed sequentially and should have a clear function. This makes the process easy to read, maintain and scale.
3. RESPONSE
   It is optional, but useful. It allows to return a response at the end of the process: a confirmation for the user or a value for another API or process.

Principles for designing good processes

1. A process = a function
   Each process should have a single objective. If your solution solves several things, divide it into different processes. This gives you order, reusability and flexibility.
2. Logical order of steps
   It's like telling a story:
   • You receive data
   • You check them
   • Action shots
   • You close with a response.

Avoid executing actions without first having the necessary data.

3. Clear names and simple conditions
   Use names that say what they do: verifyCustomer, sendWelcomeMail.
   And if you need a lot of validation, consider delegating some of that logic to another process or to the database.
4. Test step by step
   Don't wait to have the entire flow assembled for testing. Check each step separately to catch errors early and avoid chained failures.
5. Reuse what has already been built
   If there is already an existing process that validates emails or generates codes, reuse it. It saves you time and ensures consistency in your solution.

Case study: registration for a lecture

Suppose you are automating the registration to a free chat. It sounds simple, but if you don't structure the process well, it can scale badly, give errors or become unmanageable.

Purpose of the process:

• Register the person concerned
• Verify if you are already registered
• Send a personalized email
• Mark the record as processed

Nothing else. It does not handle reminders or surveys. That will be handled by other processes.

Structure of the process:

• INIT: name, email and selected chat. Nothing additional.
• STEPS:
  • Verify duplicate: if you are already registered, finish the process.
  • Record data: keeps the inscription.
  • Send mail: personalized confirmation message.
  • Update status: marked as "processed".
• RESPOND: displays a success message or delivers data for another process.

Why does this process work well?

• Has a defined purpose
• The flow is logical and clear
• Each step has only one function
• It is easy to extend if new chats appear
• It is maintainable: if something needs to be changed, you know where to do it.

Designing processes is designing solutions

It is not enough for a process to "work". It must make sense, be stable, understandable and easy to modify.
It should be able to be told as a story. If you can explain it without getting convoluted, it's probably well designed.

That's the difference between a professional solution and a temporary patch.

Where can you learn to design better?

In the MasterBase® Labs, an instance designed to explore ideas, validate structures and resolve specific doubts. If you have a specific need, you can present your conceptual design in the Lab and work directly on its implementation. This is the place where well-thought-out ideas are transformed into robust solutions.

This is how to build robust, maintainable and professional solutions.