mirror of
https://github.com/ToolJet/ToolJet
synced 2026-05-04 22:08:29 +00:00
58 lines
3.5 KiB
Markdown
58 lines
3.5 KiB
Markdown
|
---
|
||
|
|
id: permissions
|
||
|
|
title: Permissions
|
||
|
|
---
|
||
|
|
|
||
|
|
Permissions in **ToolJet Workflows** provide a structured approach to access control, ensuring precise management of who can view, edit, or execute workflows. The below table gives a detailed summary of permissions in context of ToolJet Workflows.
|
||
|
|
|
||
|
|
| Permission | Admins | Builders | End Users | Custom Groups |
|
||
|
|
|:------------------------------------------------|:------:|:----------------------------------:|:---------:|:-------------------------------------------:|
|
||
|
|
| Workflows Dashboard Access | ✅ | ❌ | ❌ | Configurable |
|
||
|
|
| Create/Edit Workflows | ✅ | ✅ | ❌ | Configurable |
|
||
|
|
| Execute Workflows | ✅ | ✅ | ✅ | Configurable |
|
||
|
|
| Using Workflows in ToolJet App Builder | ✅ | ✅ | ❌ | Configurable |
|
||
|
|
| Enable/Disable Workflows | ✅ | ❌ | ❌ | Configurable |
|
||
|
|
|
||
|
|
|
||
|
|
:::note
|
||
|
|
To trigger workflows from the App Builder, users need both Workflow permissions (to create and edit workflows) and Data Source: Create/Delete permissions (to execute them within apps), ensuring secure end-to-end workflow functionality.
|
||
|
|
:::
|
||
|
|
|
||
|
|
<div style={{paddingTop:'24px', paddingBottom:'24px'}}>
|
||
|
|
|
||
|
|
## Admins
|
||
|
|
**Admins** can create, edit, and manage workflows, access the workflow dashboard and flow builder, and use them in ToolJet's **App Builder**. They also have the option to use the **Enable** toggle on the top-right to enable or disable the execution of workflows in ToolJet applications.
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div style={{paddingTop:'24px', paddingBottom:'24px'}}>
|
||
|
|
|
||
|
|
## Builders
|
||
|
|
**Builders** can create the existing workflows in ToolJet's **App Builder**.
|
||
|
|
|
||
|
|
Example:
|
||
|
|
Imagine a company using ToolJet to build internal applications. The HR department wants to integrate a new workflow that triggers an automated email when an employee's leave request is approved. A builder with **Workflow Permissions** can:
|
||
|
|
|
||
|
|
- Add a button named *Approve Leave* in the app builder interface.
|
||
|
|
- Link this button to an existing workflow which sends an automated email.
|
||
|
|
- Design a chart that displays the number of leaves approved monthly using another workflow that provides the relevant data.
|
||
|
|
|
||
|
|
While they can harness existing workflows and integrate them into app functionalities, Groups with App Editing Permissions can't create or modify the workflows themselves like **Admins**.
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div style={{paddingTop:'24px', paddingBottom:'24px'}}>
|
||
|
|
|
||
|
|
## End Users
|
||
|
|
|
||
|
|
**End Users** can only execute workflows in the application.
|
||
|
|
|
||
|
|
Example:
|
||
|
|
Taking the same company scenario, an employee(end user) from the Sales department logs into the ToolJet-based internal application to request annual leave. Here's their interaction:
|
||
|
|
|
||
|
|
- The employee fills in a *Leave Request* form.
|
||
|
|
- Upon submission, they click the *Request Leave* button (which is linked to a workflow that sends this request to the HR department).
|
||
|
|
- Once HR approves the leave using the *Approve Leave* button (created by the "Groups with App Editing Permissions"), the employee receives an automated email notification, which is triggered by another workflow.
|
||
|
|
|
||
|
|
</div>
|