The Optimal Flowlearn
Work systems
Softr

Build internal MVPs with Softr

Learn to turn an internal need into a Softr prototype by connecting data, preparing screens and checking how different team members would use it.

Intermediate12 h · 6 × 2 hSpanish & English
Contact

Find your starting point

A good fit when you want to test a focused internal app with practice data and check its user journey before considering implementation.

Hours and sessions
12 hours live · 6 sessions of 2 h.
Group size
Up to 12 participants per trainer as a reference, adjusted to the practice and feedback.

What you will learn

  1. 01

    Define the users, tasks and essential screens for a focused internal use case.

  2. 02

    Connect practice data and configure its presentation and navigation in Softr.

  3. 03

    Check a journey with test profiles and record acceptance criteria and available access limits.

A proposed programme

You will build a prototype internal request portal with Softr and its native database. You will define the requester’s and reviewer’s tasks, prepare the essential screens and check the journey with fictional data and test users, including the access that must be blocked.

We adapt the selection and depth of the modules to the group's starting point and goals.

01

From problem to prototype

Users, tasks, data and minimum scope for a focused internal use case.

You will work on

  • Define a focused internal request and separate requester and reviewer tasks.
  • Define the minimum fields: identifier, subject, requester, status and context.
  • Write acceptance criteria for navigation, visible information and profile access.
Practice
Design the request consultation journey with a list, a detail page and a permissions table.
How you will check it
A small scope with fields, screens and testable criteria; excluded features are recorded.
02

Build in Softr

Pages, blocks and connection to a source compatible with the agreed environment.

You will work on

  • Create a practice table in Softr Databases and map its fields to list and detail blocks.
  • Prepare navigation, labels and messages so users can find a request and understand its status.
  • Configure test users and groups and apply data restrictions; distinguish these from hiding pages, blocks or buttons.
Practice
Build the portal screens and restrict the requester’s reading access to their own records while retaining the agreed review view.
How you will check it
A prototype connected to classroom data, with correct fields and defined view rules for both profiles.
03

Test the journey

Available permissions, validation with profiles and a record of remaining adjustments.

You will work on

  • Walk through the app as requester and reviewer and compare the observations with the permissions table.
  • Test a direct detail link to another person’s request and check record access, as well as its absence from the list.
  • Review the actions available on the plan and record corrections, limitations and tasks needed before any real use.
Practice
Correct a portal that filters its list but still exposes another person’s request through a direct link; repeat the tests with both profiles.
How you will check it
A test matrix showing expected and observed results and corrections; access boundaries are checked rather than inferred from the interface’s appearance.

The portal must protect the record, not simply hide it

Teaching example

Suggested practice: prototype a request portal, consult information with different test profiles and check that navigation and access support the chosen task. We document limits and remaining adjustments; features are selected around the training environment.

Fictional classroom case. Lara needs to consult her internal requests, while Diego reviews the team’s requests. The table contains two invented records: REQ-014, belonging to Lara, and REQ-015, belonging to someone else. Lara should read only her own; Diego may read both under the agreed reviewer profile.

Starting point
The table appears the same for everyone, with no profile-based view rule. The journey does not yet meet the access criteria.
First attempt
The first prototype shows only REQ-014 in Lara’s list, but a direct link to REQ-015 still opens its data. A visual filter does not demonstrate that record access is restricted.
What we review
The trainer asks the group to review the data restrictions and repeat the direct-link test as Lara. They then check Diego’s view and separately record which actions each profile can perform in the agreed environment.
Result
The corrected test lets Lara consult REQ-014 and blocks her reading of REQ-015. Diego can review both records. The group retains the configuration and test results; this remains a classroom prototype, not an app presented as ready for operational use.

Internal request portal

Classroom data

  • REQ-014 · Lara

    Own request, awaiting review.

  • REQ-015 · someone else

    Record belonging to another requester.

Requester · Lara

  • REQ-014

    View access allowed.

  • REQ-015 by direct link

    View access blocked.

Reviewer · Diego

  • Both requests

    Agreed view access for review.

  • Prototype actions

    Check rules and plan before using them.

Teaching illustration of a fictional case, not a Softr screenshot. Hiding a block does not replace checking data restrictions.

Before calling it complete

  • List and detail screens show the fields of the correct record.
  • Lara cannot read another person’s request through its direct link.
  • Diego retains the agreed view access, and actions are checked against the available rules and plan.

Sessions to put it into practice.

Reference edition · 12 h live

Reference edition: 12 live hours across 6 sessions of 2 hours. Definition, construction and prototype testing take place during the sessions. Profiles, permissions and features are confirmed before starting; any additional preparation is agreed with the group.

  1. Session 12 h

    Define the need and scope

    Choose an internal request, identify the two profiles and agree which minimum journey is worth prototyping.

    By the end

    A scope with tasks and acceptance criteria, without adding features by default.

  2. Session 22 h

    Prepare the practice data

    Create the fields in Softr Databases and load fictional records consistent with the case.

    By the end

    A request table with an identifier, requester, context and status.

  3. Session 32 h

    Build the list and detail screens

    Connect blocks and fields, prepare navigation and check interface labels and states.

    By the end

    A journey that lets someone find a request and understand its data.

  4. Session 42 h

    Define profile access

    Configure groups and view restrictions, publish their changes only in the isolated teaching prototype and check available rules before testing profiles.

    By the end

    A permissions table reflected in the prototype’s available settings.

  5. Session 52 h

    Test allowed and blocked access

    Check the journey with both profiles, including direct links to other people’s records and out-of-scope actions.

    By the end

    A test matrix with identified differences and specific corrections.

  6. Session 62 h

    Review and leave instructions

    Repeat the corrected cases with the trainer’s feedback and record how to check the prototype and what is needed before real use.

    By the end

    A reviewed classroom prototype and instructions another person can follow.

If your team needs to go further

  • Deploying the portal for operational use, migrating real data, connecting a domain and organising maintenance requires a separate scope.
  • Automations, external integrations, payments or advanced permissions beyond the agreed environment are not automatically added to this edition.

Learn with someone who designs work systems.

Guillermo Mascaraque Piña

Guillermo Mascaraque Piña

Work systems consultant

Over two years of experience designing systems for companies across industries and sizes.

Guillermo is the planned trainer for this programme. Dates, language and his availability are confirmed when the edition is agreed.

With guidance, practice and support.

Each delivery includes working materials, feedback on practical work and assessment against the agreed objectives.

See materials, support and terms

Materials you can keep

Downloadable, versioned guides, exercises and review criteria for internal use.

To prepare and complete the delivery

A short recommendation, an editable communications kit and a group learning report.

TOF’s own certificate

A certificate of achievement after the agreed assessment. It is not a vendor certification.

A month of email support

On the content covered, up to two accumulated hours for the whole group.

Your team carries out the practice. Implementation services are agreed separately. See the scope →

Softr Partner

Softr Partner

We are a Softr Partner. Our experience with apps and portals brings context to working with data, permissions and user journeys.

A TOF solution published by Softr ↗

The partnership belongs to The Optimal Flow. Learn’s certificate is issued by TOF; it is not a vendor certification.

Keep learning

Other options for the task you want to work on. Each link explains what that programme adds.

Work systems

Team innovation with Miro

To clarify the problem and compare ideas with the team before selecting the prototype screens.

View course
Artificial intelligence

Create internal apps with vibe coding

To explore another approach to prototyping with AI through specifications, changes and behaviour checks.

View course

What does your
team need to learn?

Tell us what you want to work on, how many people would take part and where you are based. We will prepare a proposal with scope, sessions and a budget.

Contact

Would you like to ask about FUNDAE?

We check eligibility for each company and edition, subject to requirements and available training credit in Spain. Funding is neither automatic nor guaranteed. Official FUNDAE information ↗

Discuss eligibility
The Optimal FlowlearnSoftr

Build internal MVPs with Softr

Learn to turn an internal need into a Softr prototype by connecting data, preparing screens and checking how different team members would use it.

12 live hours6 sessions of 2 hoursIn Spanish or English

Reference edition: 12 live hours across 6 sessions of 2 hours. Definition, construction and prototype testing take place during the sessions. Profiles, permissions and features are confirmed before starting; any additional preparation is agreed with the group.

Who it is for

Operations, product or systems professionals exploring internal applications without coding the entire interface. Focused on learning and prototyping.

By the end you will be able to

  • Define the users, tasks and essential screens for a focused internal use case.
  • Connect practice data and configure its presentation and navigation in Softr.
  • Check a journey with test profiles and record acceptance criteria and available access limits.

Before we begin

A Softr account, editor access and an authorised, compatible practice data source. Permissions covered depend on the plan and configuration; operational deployment and maintenance are agreed as a separate scope.

We will use Softr Databases, fictional records and two test profiles: requester and reviewer. We confirm editor access and a plan supporting the agreed groups and restrictions. Global view restrictions are available on every plan; that does not mean every group or permission is free. Create, edit and delete restrictions require Business or above. We check the environment before the edition; operational deployment is outside the course.

Your trainer

Guillermo Mascaraque Piña
Work systems consultant

Over two years of experience designing systems for companies across industries and sizes.

Guillermo is the planned trainer for this programme. Dates, language and his availability are confirmed when the edition is agreed.

Course online · theoptimalflow.com/en/learn/courses/softr-internal-mvpsinfo@theoptimalflow.comVersion 1 · Document reviewed: 13 October 2026
The Optimal FlowlearnBuild internal MVPs with Softr

Programme sessions

  1. Session 1 · 2 h

    Define the need and scope

    Choose an internal request, identify the two profiles and agree which minimum journey is worth prototyping.

    Result: A scope with tasks and acceptance criteria, without adding features by default.

  2. Session 2 · 2 h

    Prepare the practice data

    Create the fields in Softr Databases and load fictional records consistent with the case.

    Result: A request table with an identifier, requester, context and status.

  3. Session 3 · 2 h

    Build the list and detail screens

    Connect blocks and fields, prepare navigation and check interface labels and states.

    Result: A journey that lets someone find a request and understand its data.

  4. Session 4 · 2 h

    Define profile access

    Configure groups and view restrictions, publish their changes only in the isolated teaching prototype and check available rules before testing profiles.

    Result: A permissions table reflected in the prototype’s available settings.

  5. Session 5 · 2 h

    Test allowed and blocked access

    Check the journey with both profiles, including direct links to other people’s records and out-of-scope actions.

    Result: A test matrix with identified differences and specific corrections.

  6. Session 6 · 2 h

    Review and leave instructions

    Repeat the corrected cases with the trainer’s feedback and record how to check the prototype and what is needed before real use.

    Result: A reviewed classroom prototype and instructions another person can follow.

A fictional classroom case

The portal must protect the record, not simply hide it

Fictional classroom case. Lara needs to consult her internal requests, while Diego reviews the team’s requests. The table contains two invented records: REQ-014, belonging to Lara, and REQ-015, belonging to someone else. Lara should read only her own; Diego may read both under the agreed reviewer profile.

By the end of the exercise: The corrected test lets Lara consult REQ-014 and blocks her reading of REQ-015. Diego can review both records. The group retains the configuration and test results; this remains a classroom prototype, not an app presented as ready for operational use.

Course online · theoptimalflow.com/en/learn/courses/softr-internal-mvpsinfo@theoptimalflow.comVersion 1 · Document reviewed: 13 October 2026
The Optimal FlowlearnBuild internal MVPs with Softr

What we will work on

From problem to prototype

  • Define a focused internal request and separate requester and reviewer tasks.
  • Define the minimum fields: identifier, subject, requester, status and context.
  • Write acceptance criteria for navigation, visible information and profile access.

Practice: Design the request consultation journey with a list, a detail page and a permissions table.

Build in Softr

  • Create a practice table in Softr Databases and map its fields to list and detail blocks.
  • Prepare navigation, labels and messages so users can find a request and understand its status.
  • Configure test users and groups and apply data restrictions; distinguish these from hiding pages, blocks or buttons.

Practice: Build the portal screens and restrict the requester’s reading access to their own records while retaining the agreed review view.

Test the journey

  • Walk through the app as requester and reviewer and compare the observations with the permissions table.
  • Test a direct detail link to another person’s request and check record access, as well as its absence from the list.
  • Review the actions available on the plan and record corrections, limitations and tasks needed before any real use.

Practice: Correct a portal that filters its list but still exposes another person’s request through a direct link; repeat the tests with both profiles.

Extensions agreed separately. Deploying the portal for operational use, migrating real data, connecting a domain and organising maintenance requires a separate scope. Automations, external integrations, payments or advanced permissions beyond the agreed environment are not automatically added to this edition.

What accompanies the programme

  • A downloadable, versioned guide, exercises and review criteria; keep a copy for internal use.
  • A short recommendation, editable kit and group learning report. Responsibilities, a prior access check, handover and recipients are agreed for each delivery.
  • TOF’s own certificate of achievement after passing the agreed assessment. It is not a vendor certification.
  • Email support on the content covered for one calendar month after the last session. A maximum of two accumulated hours for the whole group, with a response time of up to two working days.

Clients provide licences unless expressly agreed otherwise. Recordings are agreed in advance. Implementation, work carried out independently by TOF, production deployment and ongoing maintenance are quoted separately. Delivery link access is agreed per delivery. Later updates and specific support require agreement. Structured documents and text alternatives; participation needs reviewed before starting.

Full format and terms → theoptimalflow.com/en/learn/how-we-teach
Course online · theoptimalflow.com/en/learn/courses/softr-internal-mvpsinfo@theoptimalflow.comVersion 1 · Document reviewed: 13 October 2026