Why Submission Access Can Be Tricky

Submission access is critical to building secure and reliable applications on the Kinetic Platform. Even if a user can see a form, they may not be allowed to view its submissions, especially in dashboards, reports, or API queries.

This guide walks through how submission access works, what can go wrong, and how to avoid frustrating errors.

Why Submission Access Matters

When building reporting views or using searchSubmissions, the system must evaluate whether the user has permission to see each individual result.

If a user tries to retrieve submissions they aren't authorized to view, those records are silently excluded, but if too many are excluded, the entire query fails.

Platform Query Limits

To protect performance and security, the platform limits how many inaccessible submissions a user can encounter before it aborts the request.

⛔

If a user encounters more than 10 submissions they are not allowed to see, the entire query will fail.

This limit applies to:

• Form dashboards
• Custom reports
• API calls like searchSubmissions

How Submission Visibility Is Controlled

Submission access is governed by:

• Submission Display security policies (at the Form, Kapp, or Space level)
• Security definitions that evaluate who can see each submission

If no submission-level policy is defined, access falls back to higher-level policies based on the Access Control Hierarchy.

Common Access Patterns

Recommended Pattern:

values('Requested For') === identity('username') ||
hasIntersection(values('Assigned Team'), identity('teams'))

 

This rule allows:

• The submitter to see their own request
• Managers or reviewers in the assigned team to see it too

Overly Restrictive Pattern

identity('username') === values('Assigned Individual')

This blocks visibility for everyone except one person, potentially excluding help desk teams, approvers, or dashboard viewers.

Tips to Avoid Query Failures

• Test dashboards and search queries with real user roles (not just as a Space Admin)
• Use team- or role-based visibility whenever possible
• Use default values in your bindings (e.g., identity('teams', [])) to avoid null errors
• Logically group submissions in your UI to reduce risk of wide queries (make sure your queries match your rules to avoid erroring out)
• Use summaries or stats when full submission access isn't required

Summary

• Submission visibility is not guaranteed, even if a user can see the form
• Exceeding 10 denied submissions causes query failures
• Use well-scoped security definitions to balance privacy and usability

Related Topics

• Access Rules & Permissions (Security Policies)
• Access Logic (Security Definitions)
• Securing Workflow Access