Security Context

The security context lets you control script execution based on the invoking user and their roles.

Invoking user

The invoking user is someone who performed an action that triggered the script execution.

For example; you pressed a button, so you are the invoking user.

Security context lets you define the invoking user, to permit operations over resources that the actual user may not have access to. For example, you can permit regular users to access records via automation scripts, but not directly via the record list.

Deferred and sink scripts require you to specify the security context as the invoker is not known.

An example of defining an invoking user:

// This security context forces the system to use some-user-identifier-here when executing the script
export default {
  trigger (t) {...}

  security: 'some-user-identifier-here',

  exec (args, ctx) {...}
}

You can use the user’s handle, email or ID as the some-user-identifier-here value.

Forcing the invoking user is only available for server scripts.

We suggest you create a new system user that is responsible for the script execution. For example, our DocuSign extension requests a new ext_docusign user.

Restricting script execution

Security context lets you prevent specific users from performing specific operations. For example, you can prevent regular users from signing documents or sending quotes.

Use these properties when defining the context:

allow: specifies what roles are permitted to trigger the automation script.
deny: specifies what roles are not allowed to trigger the automation script.

If a user is not allowed to trigger an explicit script (a button), the button is shown as disabled.

An example of permitting access:

// This security context only permits the administrator and superuser to trigger the script.
// Other roles will not be able to trigger it.
export default {
  trigger (t) {...}

  security: {
    allow: ['administrator', 'superuser'],
  },

  exec (args, ctx) {...}
}

An example of denying access:

// This security context permits all roles but the client and lead.
export default {
  trigger (t) {...}

  security: {
    deny: ['client', 'lead'],
  },

  exec (args, ctx) {...}
}