Security Policy Basics


Security policies are definable expressions that control who is authorized to access/create/modify/delete specific resources.

Parts of a Security Definition

Each Security Definition has the same four elements.


The Name is descriptive text that is presented in dropdowns. It must be Unique, even if it is for a different type.


Because there is a different scope between Space and kapps, there are different types available.

Avaialble Types for Space:

Type (where they can be used)Available Bindings
Spaceidentity(...), space(...)
Teamidentity(...), space(...), team(...)
Useridentity(...), space(...), user(...)
Datastore Formidentity(...), space(...), form(...)
Datastore Submissionidentity(...), space(...), form(...), submission(...)

Avaialble Types for Kapps:

Type (where they can be used)Available Bindings
Kappidentity(...), space(...), kapp(...)
Formidentity(...), space(...), kapp(...), form(...)
Submissionidentity(...), space(...), kapp(...), form(...), submission(...)


The message is what is returned to the customer if the Rule evaluates to false.


The Security Definition rule is a single JavaScript expression that has to evaluate to either true or false.


Security Definitions are used throughout the application to provide limits on access to different elements like forms, kapps, and submissions.



Security policies give us the ability to apply security that is logically easy, but impossible to implement with traditional group based security.

  • Ex: “A user can access this form if they are NOT in a specific team”
  • Ex: “A user can access this form if they have a matching attribute"
  • Ex: “A user can access this form if they are in Team A AND in Team B”
  • Ex: “This form is only available on “Weekends”
  • Ex: “This process is usable by people who have been employed > 1 year"

Security Policy Precedence

The Kinetic Platform leverages a number of nested scopes. Security Policies evaluate the highest scope first, and proceed until all appropriate policies have been evaluated.

  • Users with Space Admin privileges bypass all security policy evaluation
    • This is why invalid security policies sometimes don’t show up until users without Space Admin permissions begin using the system
  • If someone can modify a Kapp, they can access/create/modify all Forms and Submissions in that Kapp
    • This is new in Platform v5, pre-v5 Submissions were independent of Kapp Modification security
  • If someone can modify a Form, they can access/create/modify all Submissions of that Form

Submission Searching

Security policies needed to be coordinated with submission search patterns

  • Security Policies can not be a replacement for submission searching
  • If there are more than 25 submissions encountered in a search that the Submission Access policy denies, the entire query fails
    • Security Policies must be evaluated after querying the database
    • We limit failures to avoid "table scans" and the resulting performance degradation
Example Search:All submissions where the Assigned Team is “Facilities”
Example Good Submission Access Policy:The current user is in the Facilities Team
Example Bad Submission Access Policy:The current user has the attribute “Manager” set to true