Path | Duration | Level | Before you start |
🏁 Final project | 3 h | Advanced | Configurator · Level 1 and Level 2 paths · Recommended: Analysis |
So far you have built the Packaging control following instructions. In the final project there are no steps: you choose a process, design it and build it yourself. It is the best way to check that you know how to use Mairu, and the one we recommend to partners to validate their training.
🎯 By the end you'll have shown that you know how to
Turn a business need into a Mairu design before configuring anything.
Choose and combine the right pieces: master data, form, subform, rules, events, queries, schedules or automations, dashboard and Power BI.
Test the process from start to finish with different profiles.
Explain your design decisions.
🧭 Step 1 · Choose your process
Use the real process you identified in the challenge of lesson 1, or choose one of these:
Process | What it puts to the test | Reference case | |
Purchase request and approval | Statuses, permissions per profile, notifications | [[Caso de uso - Flujo de solicitud y aprobación | Use case - Request and approval flow]] |
5S audit with scoring | Formulas, thresholds, statuses, KPI | [[Caso de uso - Auditoría con puntuación y seguimiento | Use case - Audit with scoring and follow-up]] |
Machine startup checklist with signature | Step by step, signature, PDF, rules | [[Caso de uso - Checklist de inspección con firma y PDF | Use case - Inspection checklist with signature and PDF]] |
Control of expiring training | Entities, date scripts, automations | [[Caso de uso - Control de formaciones y certificados que caducan | Use case - Controlling training and certificates that expire]] |
Work order with time logging | Stopwatch, subforms, indicator queries | [[Caso de uso - Parte de trabajo con registro de tiempos | Use case - Work order with time logging]] |
Preventive maintenance | Assets, schedules, tasks, Power BI | [[Gestionar un plan de mantenimiento preventivo autónomo | Manage an autonomous preventive maintenance plan]] |
Maintenance incidents | Rules, chained events, scheduling | [[Gestionar una incidencia de mantenimiento de principio a fin | Manage a maintenance incident from start to finish]] |
Material entries and consumption | Products, update stock, stock levels | [[Gestionar entradas, consumos y existencias de productos | Manage product entries, consumption and stock]] |
⚠️ Read the reference case only after doing your design, to contrast it. If you read it before, you will be copying, not designing.
📝 Step 2 · Design before building
Answer these six questions in writing (half a page is enough):
What information is recorded? Fields, types, what is master data and what is written.
What decisions does the form make while it is being filled in? → rules.
What must happen after saving? → events.
Who acts and when? → profiles, permissions, schedules, statuses.
How is the follow-up done? → history, dashboards, automations.
How will it be analyzed? → queries, KPI, Power BI.
Then complete the Need → Mairu piece table, as in lesson 1.
🛠️ Step 3 · Build
Build the process in your test environment. Your solution must include, as a minimum:
[ ] At least one master data (Asset, Product, Entity…) used with its selector.
[ ] A published form, with clean IDs and permissions for at least two profiles.
[ ] A subform or a table, justifying the choice.
[ ] At least two rules (one of visibility or mandatoriness and one of calculation).
[ ] A custom status group and at least one event that updates it.
[ ] At least one alert (email or notification) with form data in the message.
[ ] A query tested with Testing and used in a field or in a widget.
[ ] A schedule or an automation.
[ ] A Summary configured: history, mobile card and PDF.
[ ] A dashboard for at least one profile, configured as its initial route.
[ ] (Optional) A Power BI report or a Webhook.
🔍 Step 4 · Test as they will use it
Create a test user per profile and go through the complete process with each one:
Does each profile see only what it should see?
Can the form be filled in on mobile, even offline?
Do the alerts arrive only once, to the right person, with useful information?
Do the statuses reflect where each record is?
Would someone who doesn't know the process understand the dashboard in 10 seconds?
🏅 Step 5 · Validate your project
Use this rubric to self-assess. If you are a partner, share it with your Mairu contact together with a demonstration of the process.
Criterion | 0 · Doesn't meet | 1 · Meets | 2 · Stands out |
Prior design | Built without a design | Design with the six questions | Design justified and contrasted with the reference case |
Master data | Free texts where there should be master records | Correct master records | Master records reusable by other processes |
Structure | Field 1, Field 2… for repeated data | Subform or table well chosen | Designed for later analysis |
Rules | Static form | Rules that work | Simple rules, with a clear name and no duplication |
Events and alerts | Alerts that always fire or never arrive | Alerts with a condition | Useful alerts, with no duplicates and with coherent statuses |
Queries | No queries or with errors | A query that works | Queries with parameters that avoid rewriting data |
Follow-up | No schedules or dashboard | Schedule or automation and dashboard | Dashboard per profile with initial route |
Permissions | Everyone sees and edits everything | Permissions per profile | Minimum necessary permissions, tested with real users |
Result: 12 points or more, project validated. 14 or more, advanced level.
🎓 And now?
Review the Best practices in the help center: they are the next level after these lessons.
Check the Use cases to discover new patterns.
If something you have built doesn't turn out as you expected, write to us through the chat indicating the lesson and the step: it helps us improve this course.
📚 Learn more
⬅️ Back to start: How to learn Mairu with the Lessons