Empty FileMaker portal? Show the right message and next action

An empty rectangle does not explain what happened

A portal can be empty because no parent is selected, because there are no accessible related rows, or because a filter removed every visible match. Those situations need different messages.

Show the reason you can establish and an appropriate next action. Do not say “No tasks exist” when the only thing you know is that the current user cannot see any. Do not display a zero count when the query failed.

Choose words that match the state

The “accessible tasks exist” distinction is only safe when the user is permitted to know that broader set. If your security design intentionally hides it, use “No tasks to show for this selection” instead. Never obtain a broader count with a full-access script just to improve a message.

Use the portal’s rule, not an unrelated total

A relationship count and a portal-filter result are different things. Counting all related IDs can produce a nonzero value while a status filter hides every displayed row. Claris explains this distinction in Working with related data in portals. Begin with a reliable view evaluator and make the message consume its result.

For a small teaching file, the evaluator can inspect the selected project’s accessible tasks in a separate worker context, skip inaccessible records, apply the same status predicate as the portal, and return both authorized total and displayed count. Keep the result invalid until the evaluation finishes. Never run it with elevated privileges.

Task belongs to selected project
AND user may access the task
AND (filter is All OR Task.Status exactly matches selected status)

For a large hosted solution, avoid enumerating a large related set on every keystroke. Design an efficient authorized query or relationship and verify that it produces the same visible set. Reuse one definition of the filter predicate rather than maintaining two slightly different rules.

Keep loading failures out of the empty state

Assume the view evaluator has set these session UI globals: gParentID, gViewReady, gLoadError, gVisibleCount, gAccessibleCount and gFilterActive. Counts are valid only when gViewReady is true and gLoadError is false.

Case (
    IsEmpty ( UI::gParentID ) ;
        "Select a project to see its tasks." ;
    UI::gLoadError ;
        "Tasks could not be loaded. Try again." ;
    not UI::gViewReady ;
        "Loading tasks…" ;
    UI::gVisibleCount > 0 ;
        "" ;
    UI::gFilterActive and UI::gAccessibleCount > 0 ;
        "No tasks match this filter." ;
    "No tasks available in this project."
)

Place this text beside or over the empty portal area and hide it when the result is empty. Keep its action buttons outside the portal row so they remain available when there are no rows. The calculation does not compute the counts; those must come from the verified evaluator described above.

Refresh the message and the view together

When the parent or filter changes, invalidate the old counts immediately. Recompute the view, refresh the portal, and update the message from the same result. A delayed refresh must not leave “No tasks match” over newly visible rows.

Test one project with no tasks and one with two completed tasks. Select an Open-only filter for the second project: the message should offer Clear filter. Clear it: both permitted tasks appear and the message disappears. Then switch parents and repeat.

Finally test restricted access, a loading error and Add task permission. The message must neither reveal hidden records nor offer an action the user cannot complete. If the portal itself is unexpectedly empty, fix that underlying issue before adding explanatory text.