Platform Guide
Integrations LibraryGet in Touch!

Access Rules & Permissions (Security Policies)

Suggest Edits

Security Policies

Security policies control what users can see, update, or interact with across the Kinetic Platform. Whether you're building a workflow, designing a form, or setting up team access, policies help you enforce the right rules at the right level.

Policies are powered by security definitions, which are flexible JavaScript rules that evaluate user identity, team membership, attributes, and more.

Security Policy Hierarchy

Security policies follow a clear inheritance hierarchy, where the platform checks from the most specific to the most general level.

In ascending order of scope and fallback:

  1. Form
  2. Kapp
  3. Space

If a policy is not defined at the form level, the platform checks the kapp. If none is defined at the kapp level, it uses the space-wide default.

This means:

  • Define policies at the lowest level possible to ensure the most accurate control.
  • Only use space-level policies as fallbacks or broad rules for all users.

Form-Level Policies (Most Specific)

These are policies applied directly to an individual form. These are the most targeted and recommended for use when possible.

  • Form Display – Who can see or access the form
  • Form Modification – Who can update the form definition
  • Submission Display – Who can view individual submissions
  • Submission Modification – Who can update submissions
  • Allow Anonymous Submissions – (Toggle)

Found under: Form > Settings > Security

See An Example


Kapp-Level Policies

Used to define default policies across all forms within a kapp. If no form-level policy is set, these rules apply.

  • Default Form Display / Modification
  • Default Submission Display / Modification
  • Kapp Display (who sees the kapp)
  • Kapp Modification (who can change kapp configuration)

Found under: Kapp > Settings > Security

See An Example


Space-Level Policies (Global Fallback)

Space-wide policies act as a global safety net. These typically manage administrative permissions and default behaviors when no other level provides a rule.

  • Who can create, modify, or view:
    • Users and Teams
    • File Resources
    • Spaces and Kapps
  • Admin Console access
  • API and system-level access

Found under: Space > Settings > Security

See An Example



Applying a Security Policy

To apply a policy:

  1. Navigate to the Form, Kapp, or Space you want to secure
  2. Go to the Security tab
  3. Select an existing Security Definition or create a new one
  4. Assign the definition to a specific policy type (e.g., Submission Display)

Learn more about creating definitions in the Security Definitions page.

Best Practices

  • Start small: Use form-level policies first before defining broad kapp/space rules
  • Reuse definitions: Keep logic consistent and avoid duplication
  • Test with a non-admin account: Always confirm what different users can see
  • Be cautious with Submission Display:
    • If a user tries to retrieve 25+ submissions they can’t access, the query fails

⚠️

Heads up! Space Admins bypass security policies.

When testing access rules, keep in mind that Space Admins automatically have full access, regardless of form, kapp, or submission-level policies.

To properly validate your security configurations, always test with a non-admin user account that reflects your intended access scenario.

Real-World Examples

  • "Only users in the HR team can submit onboarding forms"
  • "Users can only view their own submissions"
  • "Form should only be visible during business hours"
  • "Only assigned reviewers can update a request after submission"

Related Topics

Updated 7 days ago