Accessing static data from non "code" nodes

The idea is:

Accessing the static data directly in other nodes than the “code” node type, with the expression {{ $getWorkflowStaticData(‘global’) }}

What is the reason of doing so?

Actually, it would be great if there will be a node that can work with the static data (e.g. create, update, read the static data), as it’s an SQL query to the database in the nutshell. But I don’t see the benefits of using it in the Edit Fields node

1 Like

Actually it’s not for the edit node, but for a google sheet node. The previous screen with the edit node was for the example.

I’d like to store sheets ids associated to their names in the static data.
For my usecase workflow (see the screen below), there are 12 ghseet nodes used in 2 different main branches, with only 3 different google sheets. I can easily mix google sheet ids this way and create errors.

So it’d be great if I can do something like this:

I’d be easier to access the right sheet id by calling it from the static data.

Thanks,

But why you need the staticData for that? You can define the name/id mapping in the Edit Fields node and refer to it

I have 2 different triggers to start 2 different paths where I need to use google sheet ids.
Without static data, I’d have to set 2 different edit nodes with these informations. Meaning 2 different places to maintain the same info.

I know 2 isn’t that much and it’s not blocking of course. But I thought it’d be more confortable and lots of use cases could have more than 2 paths.
With static data, I’d have to set it once since it’s made to be accessed from everywhere. It could make the work with n8n workflows even easier in many cases with this new feature.

Thats make sense, but I would prefer to use the sub workflow with the “staticData” defined in the Edit Field node. Then you can call that workflow in every trigger you have. That will also simplify the troubleshooting.

One of the reasons why staticData is more a hidden feature is that you can easily ruin the database or n8n itself, if you won’t be accurate. And it won’t be easy to remove the staticData once it is set (I had one case when I had to edit the DB manually to remove ~50mb of staticData because n8n kept restarting every minute :sweat_smile:)

Yes it’s like what I did. But it requires 1 new code node for each path triggered to return the ‘edit’ node output, so we can use it in other nodes types than code, I didn’t find this really smooth, but it’s not critical. Thank you for your answer.

No, you don’t need anything additional. Example for the “staticData WF”

And hot to use it

1 Like

Thank you for sharing this example.
Yes, it would require 2 workflows then.
I believe it would be useful and convenient for this use case to have a simpler way, with just one workflow.
I couldn’t help but think that using static data in all node types could be really helpful and make workflow building even faster than it already is. That’s why I made this feature request.