hey, and welcome to video number eight of the advanced course for NN. In this video, we'll be covering some Enterprise features that'll really help you with more advanced workflow building. The first very useful feature um we're going to talk about in the Enterprise set is having different kinds of access that are available to users, and starting in this case with user management. There are three types of levels of users: owner, admin, and member. These users will have different access levels when it comes to workflows or credentials to ensure that no one has unwanted access to any of the workflows in your anend instance um but also to API Keys, credentials, or any other tools. There's only one owner for every nend in. They have all of the rights listed below: adding, removing users, seeing and sharing workflows, credentials, but also setting up and using Source control. What's important to note is you cannot transfer ownership of an ENT instance. It is also important to note that even though they have access to all the credential information, they can't actually read the sensitive information itself, so they will be able to use and

share credentials but not access the underlying API key or other information. Admins are like owners, except that they can't access the dashboard or manage the owner role, whereas members are just your run-of-the-mill normal users and can manage their own accounts and workflows. The second feature we will cover is saving execution data, making it a lot easier to find executions that deal with certain information. This avoids you having to search through hundreds or thousands of executions one by one to find a specific execution. The execution data node lets you save fields or values that you want to use later to easily find an execution, for example, an order ID or a user ID. You will be able to search data by this key and value in your executions tab. We'll see in a second, for example, here the input data of the execution data node includes an order ID. I can save this ID to make it easily searchable later from the execution history tab. You can filter by key and value here, for example, we search for executions where the order ID was equal to the one from

the previous example when working with orders, transactions, products, or any other type of object that has an ID. Consider saving them to make them more easily searchable. Nidan uses git-based Source control to support environments. Linking your NN instance to a git repository lets you create multiple NN environments backed by git branches. Git is a version Control software, and NN environments let you control Version Control your NN instance using git. There are different advantages to having more than one environment. A common pattern is to have different environments for both development work and production. Development is where we do work and make changes or test updates to workflows, and production is going to be our live environment that the business depends on. A setup like this helps you make changes to workflows without breaking workflows that are already in use. This will come in very handy, especially if you have business-critical workflows. You can find a full guide on how to Version Control your Nidan instance in the Nidan documentation under Source control environments. This is highly recommended for any NN instance that runs workflows.

that the business depends on, for example, customer-facing automations or anything that might have to deal with inventory or stock that would directly impact the business should they start failing due to an update. Custom variables are read-on and can be used to store and reuse values across workflows. They can be used to store commonly used information such as IP addresses, URLs, etc., on a per-environment basis for the whole team to reference more easily. Variables can be configured by environment, and this is important to note. Let's say you have a variable with the name database in both production and development environments. The value is set to the dev database path in the dev environment and the production database path in the production environment. Then you can run the identical workflow referencing the variable name database, and it will read SLR to a different database as defined in each instance. This means no more pushing to production and then realizing you forgot to change the name of your variable. You can create a new variable from the variables page by signing it a key-value pair. Keys are under 50

characters and values under 220. You can then access the value of the variable using dollars VAR in the expressions or in the code node, as we see below. Here, I wrote dollars vs. company Tax ID, and I was able to read the environment variable. You can also use an external Secrets store to manage credentials for aniden. Aniden stores all of your credentials encrypted in its database and restricts access to them by default. But with the external Secrets feature, you can store sensitive credential information in an external Vault and have in then loaded only when required. This provides an extra layer of security and allows you to manage credentials used across multiple NN environments in one central place. You can use external secrets with any environments to create different environments backed by git. The feature doesn't support using different credentials in different instances, but you can use an external Secrets Vault to provide different credentials for different environments by connecting each inent instance to a different Vault or project environment. For example, you can have two Inn instances, one for development and one for production, as mentioned earlier.

and use HashiCorp vault in HashiCorp. Create a project with two environments, one for development and one for production, by generating a token for each HashiCorp environment. You can use the token for the development environment to connect your development instance, and the token for your production environment to connect with your production instance. Another very useful Enterprise feature is log streaming. Log streaming allows you to send events from your instance to your own logging tools. This allows you to manage your monitoring, alerting, and logging processes from the settings. You can access the log streaming tab when you create a new event destination. You start by selecting the type of destination: is it a webhook, Sentry, or syslog, for example? Then you can set up all the information necessary for the given destination. In the case of webhooks, we would have the method, URL, and we also have options to add query parameters, headers, and additional options for redirects, proxy, timeouts, etc. From here, we can select the types of events that we want to stream to the

destination. There are events related to AI workflows, audit node executions, um, audit events can also be anonymized, and these can all be found from here. We can select the type of event that we want to stream to that destination. There are events related to audits; they can be anonymized, AI workflows, node executions, etc. Audit events are going to be useful for compliance regulations. You can find a lot more information about log streaming in the nland documentation linked below. So, to illustrate um execution data saving, uh, here I have a pretty simple workflow that listens for web hooks on a URL and returns information such as the order ID, the order name, customer ID, customer email, etc. From here, the workflow sends a slack message for reporting purposes, and depending on the state of the workflow, is going to add it to Google Sheets or insert a line into the SQL database. If we have hundreds or thousands of executions coming in per day, it can be difficult to find a specific execution. So, what we can do here is add the execution data node and drag in a new

saved field. So here, this could be, for example, the order ID, and I can drag this in. So when I execute this node, it will save the order ID and associate it with this execution, which means that if I then want to go into the execution log, I can now filter by order ID and match it up with, I think it was 5 4 32, no, and match it up with the order ID, which was 53452. And here we can see this was executed today, meaning it's very easy for me to go back and find this execution. For the other Enterprise features, most of them can be found in the settings panel. So here, you're going to find information about users or log streaming environments, external secrets, and here in the tab to the left, you can find variables if you want to add new variables and use them per environment in your instance. Thanks for listening to the ETH video of the Niden advanced course, where we covered the Niden Enterprise features.

n8n Advanced Course (8/8) - Enterprise features

n8n Advanced Course (8/8) - Enterprise features

Scripts