Workflow Templates Aren't Tagging Correctly

Workflow Templates Aren’t Tagging Correctly

I hope all is well! I have a handful of Lusha workflows in n8n’s workflow repo but the pre-populated Lusha search result, with the logo, returns no results. It only works when you do a broad search for the templates show up. Here are some screenshots, showing one query yielding 13 results where, when clicking the logo, zero.
Hoping there’s an easy adjustment here that I’m missing :slight_smile:

Hey @JOtt, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@hubschrauber, @Shirobachi - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

Hi @JOtt — I ran a few public API queries on the template library and I think the behaviour is consistent, so here is what I measured (you can re-run all three yourself):

  1. Text search returns 13 templates:
    https://api.n8n.io/templates/search?search=lusha&rows=20totalWorkflows: 13
    Looking at the node list on each of those 13 results, they show Google Sheets, HTTP Request, Slack, HubSpot, Code — none of them actually contains a Lusha node. They mention Lusha in the title/description and call the API through HTTP Request or Code.

  2. The app filter (what the logo click uses) returns nothing:
    https://api.n8n.io/templates/search?apps=Lusha&rows=20totalWorkflows: 0

  3. Sanity check that the filter itself works:
    https://api.n8n.io/templates/search?apps=Google%20Sheets&rows=5totalWorkflows: 3652

So the parameter and endpoint are fine — the zero is a real zero, not a broken query.

The reading that fits all three: the app/logo filter indexes the node types that actually exist in the template JSON, while the text search also matches the title and description. A template that says “Lusha” in its name but performs the enrichment via HTTP Request never registers under the Lusha app, which is exactly the mismatch you are seeing (13 vs 0).

If that is right, the fix is on the template side rather than the search side: templates need to use the actual Lusha node to appear under the Lusha logo. Anything published before the node existed (or written against the REST API directly) will stay invisible to the logo filter no matter how many times “Lusha” appears in the text.

One caveat so you can weigh this properly: I verified this against the public search API, and I am inferring that the website’s logo filter hits the same backend — the match between the two results is strong evidence, not proof. If someone from the templates team can confirm the indexing rule, that would settle it.

This is such a thorough investigation, thank you SO MUCH @the43sunsets!

I just reached out to our template team in regards to implementing the required node. Good to know it’s not a query issue.

Much appreciated!

Glad it helped — and thanks for closing the loop! Great to hear your template team is on it.