Frederik Duchi
Workflows by Frederik Duchi
Automate process improvement with employee feedback using AI and Baserow
This n8n template demonstrates how to automatically process feedback on tasks and procedures using an **AI agent**. Employees provide feedback after completing a task, which is then analyzed by the AI to suggest improvements to the underlying procedures. Improvements can be to update how to execute a single tasks or to split or merge tasks within a procedure. The management reviews decides whether to implement those improvements. This makes it easy to close the loop between execution, feedback, and continuous process improvement. Use cases are many: - Marketing (improve the process of approving advertising content) - Finance (optimize the process of expense reimbursement) - Operations (refine the process of equipment maintenance) ## Good to know - The automation is based on the Baserow template for handling [Standard Operating Procedures](https://baserow.io/templates/standard-operating-procedures). However, it can also be implemented in other databases. - Baserow authentication is done through a database token. Check the [documentation](https://baserow.io/user-docs/personal-api-tokens) on how to create such a token. - Tasks are inserted using the HTTP request node instead of a dedicated Baserow node. This is to support batch import instead of importing records one by one. ## Requirements - Baserow account (cloud or self-hosted) - The Baserow template for handling [Standard Operating Procedures](https://baserow.io/templates/standard-operating-procedures) or a similar database with the following tables and fields: - `Procedures` table with general procedure information like to name or description . - `Procedures steps` table with all the steps associated with a procedure. - `Tasks` table that contains the actual tasks based on the procedure steps. - must have a field to capture `Feedback` - must have a boolean field to indicate if the feedback has been processed or not. This to avoid that the same feedback keeps getting used. - `Improvement suggestions` table to store the suggestions that were made by the AI agent. ## How it works - **Set table and field ids** - Stores the ids of the involved Baserow database and tables, together with the information to make requests to the Baserow API - **Feedback processing agent** The prompt contains a small instruction to check the feedback and suggest improvements to the procedures. The system message is much more extensive to provide as much details and guidance to the agent as possible. It contains the following sections: - Role: giving the agent a clear professional perspective - Goals: allowing the agent to focus on clarity, efficiency and actionable improvements. - Instructions: guiding the agent to a step-by-step flow - Output: showing the agent the expected format and details - Notes: setting guardrails for the agent to make justified and practical suggestions. The agent uses the following nodes: - OpenAI Chat Model (Model): the template uses by default the gpt-4.1 model from OpenAI. But you can replace this with any LLM. - current_procedures (Tool): provides information about all available procedures to the agent - current_procedure steps (Tool): provides information about every step in the procedures to the agent - tasks_feedback (Tool): provides the feedback of the employees to the agent. - Required output schema (Output parser): forces the agent to use a JSON schema that matches the `Improvement suggestions` table structure for the output. This allows to easily add them to the database in the next step. - **Create improvement suggestions** - Calls the API endpoint `/api/database/rows/table/{table_id}/batch/` to insert multiple records at once in the `Improvement suggestions` table. The inserted records is the output generated by the AI agent. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-rows/operation/batch_create_database_table_rows) for further details. - **Get non-processed feedback** - Gets all records from the `Tasks` table that contain feedback but that are not marked as processed yet. - **Set feedback to processed** - Updates the boolean field for each task to true to indicate that the feedback has been processed - **Aggregate records for input** - Aggregates the data from the previous nodes as an array in a property named `items`. This matches perfect with the Baserow API to insert new records in batch. - **Update tasks to processed feedback** - Calls the API endpoint `/api/database/rows/table/{table_id}/batch/` to update multiple records at once in the `Tasks` table. The updated records will have their processed field set to true. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-rows/operation/update_database_table_row) for further details. ## How to use - The **Manual Trigger** node is provided as an example, but you can replace it with other triggers such as a webhook - The included [Baserow SOP template](https://baserow.io/templates/standard-operating-procedures) works perfectly as a base schema to try out this workflow. - Set the corresponding ids in the `Configure settings and ids` node. - Check if the field names for the filters in the `tasks_feedback` tool node matches with the ones in your `Tasks` table. - Check if the field names for the filters in the `Get non-processed feedback` node matches with the ones in your `Tasks` table. - Check if the property name in the `Set feedback to processed` node matches with the ones in your `Tasks` table. ## Customising this workflow - You can add a new workflow that updates the procedures based on the acceptance or rejection by the management - There is a lot of customization possible in the system prompt. For example: change the goal to prioritize security, cost savings or customer experience
Automated task generation from blueprints with Baserow & weekend-aware scheduling
This n8n template demonstrates how to automatically **create** **tasks** (or in general, records) in Baserow based on template or blueprint tables. The first blueprint table is the **master table** that holds the general information about the template. For example: a standard procedure to handle incidents. The second table is the **details table** that holds multiple records for the template. Each record in that table is a specific task that needs to be assigned to someone with a certain deadline. This makes it easy to streamline task creation for recurring processes. Use cases are many: - Project management (generate tasks for employees based on a project template) - HR & onboarding (generate tasks for employee onboarding based on a template) - Operations (create checklists for maintenance, audits, or recurring procedures) ## Good to know - The Baserow template for handling [Standard Operating Procedures](https://baserow.io/templates/standard-operating-procedures) works perfect as a base schema to try out this workflow. - Authentication is done through a database token. Check the [documentation](https://baserow.io/user-docs/personal-api-tokens) on how to create such a token. - Tasks are inserted using the HTTP request node instead of a dedicated Baserow node. This is to support batch import instead of importing records one by one. ## Requirements - Baserow account (cloud or self-hosted) - A Baserow database with at least the following tables: - `Assignee` / employee table. This is required to be able to assign someone to a task. - `Master` table with procedure or template information. This is required to be able to select a certain template - `Details` table with all the steps associated with a procedure or template. This is required to convert each step into a specific task. - A step must have a field `Days to complete` with the number of days to complete the step. This field will be used to calculate the deadline. - `Tasks` table that contains the actual tasks with an assignee and deadline. ## How it works - **Trigger task creation (webhook)** - The automation starts when the webhook is triggered through a POST request. - It should contain an assignee, template, date and note in the body of the request. - It will send a succes or failure response once all steps are completed. - **Configure settings and ids** - Stores the ids of the involved Baserow database and tables, together with the API credentials and the data from the webhook. - **Get all template steps** - Gets all the steps from the template `Details` table that are associated with the id of the `Master` template table. - For example: the master template can have a record about handling customer complaints. The details table contains all the steps to handle this procedure. - **Calculate deadlines for each step** - Prepares the input of the tasks by using the same property names as the field of the `Tasks` table. Adjust this names, add or remove fields if this is required for your database structure. - The deadline of each step is calculated by adding the number of days a step can take based on the deadline of the first step. This is done through a field `Days to complete` in the template `Details` table. - For example. If the `schedule_date` property in the webhook is set to 2025-10-01 and the `Days to complete` for the step is 3, then the deadline will be 2025-10-04 - **Avoid scheduling during the weekend** - It might happen that the calculated deadline is on a Saturday or Sunday. This Code node moves those dates to the first Monday to avoid scheduling during the weekend. - **Aggregate tasks for insert** - Aggregates the data from the previous nodes as an array in a property named `items`. This matches perfect with the Baserow API to insert new records in batch. - **Generate tasks in batch** - Calls the API endpoint `/api/database/rows/table/{table_id}/batch/` to insert multiple records at once in the tasks table. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-rows/operation/batch_create_database_table_rows) for further details. - **Success / Error response** - Sends a simple text response to indicate the success or failure of the record creation. This is to offer feedback when triggering the automation from a Baserow application, but can be replaced with a JSON response. ## How to use - Call the `Trigger task creation` node with the required parameters through a POST request. This can be done from any web application. For example: the application builder in Baserow supports an action to send an HTTP request. The Procedure details page in the [Standard Operating Procedures](https://baserow.io/templates/standard-operating-procedures) template demonstrates this action. - The following information is required in the body of the request. This information is required to create the actual tasks. ```json { "assignee_id": integer refering to the id of the assignee in the database, "template_id": integer refering to the id of the template or procedure in the master table, "schedule_date": the date the tasks need to start scheduling, "note": text with an optional note about the tasks } ``` - Set the corresponding ids in the `Configure settings and ids` node. - Check the names of the properties in the `Calculate deadlines for each step` node. Make sure the names of those properties match the field names of your `Tasks` table. - You can replace the text message in the `Success response` and `Failure response` with a more structured format if this is necessary in your application. ## Customising this workflow - Add support for public holidays (e.g., using an external calendar API). - Modify the task assignment logic (e.g., pre-assign tasks in the details table). - Combine with notifications (email, Slack, etc.) to alert employees when new tasks are generated.
Generate filtered calendar views in Baserow with external calendar integration
This n8n template demonstrates how to automatically generate **personalized calendar views** in Baserow, based on a chosen date field and a filter. Having a personalized view with only information that is relevant to you makes it easy to integrate with external calendar tools like Outlook or Google Calendar. Use cases are many: - Task management (deadlines per staff member) - Customer management (appointments per customer) - Inventory management (delivery dates per supplier) ## Good to know - You only need **a Date field** (e.g., a task deadline, due date, appointment date) and **a Link to table field** (e.g., a customer, employee, product) to make this work. - The generated calendar views can be shared as `.ics` files and imported into any external calendar application. - Authentication is done through a JWT token constructed from your Baserow username and password. - ## How it works - **Set Baserow credentials**: - Allows you to enter your Baserow credentials (username + password) and the API host path. The host is by default https://api.baserow.io, but you can change this in case you are self-hosting. - The information is required to generate a JWT token that authenticates all future HTTP request nodes to create and configure the view. - **Create a token**: - Generates a JWT token based on the information provided in the previous node. - **Set table and field ids**: - Stores the generated JWT token and allows you to enter the ids of the tables and fields required to run the automation. - **Get all records from filter table** - Gets all the records from the table you want to filter on. This is the table that has a Link to table field referencing the table with the Date field. Each record from this table will get it’s own view. - Some examples: Customers, Employees and Products. - **Create new calendar view** - Calls the API endpoint `/api/database/views/table/{table_id}` to create a new view. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-views/operation/create_database_table_view) for further details. - The body of this requests configures the new view by setting among other things a name and the date field - **Create filter** - Calls the API endpoint `/api/database/views/{view_id}/filters/` to set a filter on the view so that it only shows the records that are relevant. This filter is based on the Link to table field that is set in earlier steps. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-view-filters/operation/create_database_table_view_filter) for further details. - **Set background color** - Calls the API endpoint `/api/database/views/{view_id}/decorations/` to set a a color on the background or left side of each item. By default, the color is based on a single select field, but it is also possible to use a condition. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-view-decorations/operation/create_database_table_view_decoration) for further details. - **Share the view** - Calls the API endpoint `/api/database/views/{view_id}` to update the current view. It updates the `ical_public` property to `true` so that an ics link is created. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-views/operation/update_database_table_view) for further details. - **Update the url’s** - Updates all the records in the table you want to filter on to fill in the url to the new generated view and the url to the ics file. This can be useful if you want to build an application on top of your database. ## How to use - The **Manual Trigger** node is provided as an example, but you can replace it with other triggers such as a webhook - The included [Baserow SOP template](https://baserow.io/templates/standard-operating-procedures) works perfectly as a base schema to try out this workflow. ## Requirements - Baserow account (cloud or self-hosted) - A Baserow database with a table that has a Date field and a Link to Table field ## Customising this workflow - Change the **date field** used to generate the calendars (e.g., deadline → appointment date). - Adjust the **filters** to match your context (staff, customer, product, etc.). - Configure which fields are shown using the `/api/database/view/{view_id}/field-options/` endpoint. Check the [Baserow API documentation](https://api.baserow.io/api/redoc/#tag/Database-table-views/operation/update_database_table_view_field_options) for further details. - Add or remove optional steps such as coloring by status or sharing the ics feed. - Extend the workflow to notify staff when a new view has been created for them.