crowd.dev n8n integrationAutomate crowd.dev with n8n.

Writes an activity and the person behind it in one step. If the contributor is not in crowd.dev yet, the member record is created along with the event instead of the call failing.

• Username: a collection where each entry pairs Platform, the platform name such as twitter or github, with Username, the handle held there.
• Source ID: the ID of the activity in the platform, for example the ID of the message in Discord.
• Timestamp: date and time when the activity took place, which keeps the history in order.

Same write, minus the person. This one attaches the event to a member that already exists, which is the version you want inside a loop over contributors you have already resolved.

• Member: the ID of the member that performed the activity, usually {{ $json.id }} carried over from a Find a member step.
• Type: type of activity, a free string worth keeping consistent across every workflow that writes.
• Platform: platform on which the activity took place.

Registers an automation on the crowd.dev tenant. crowd.dev then posts data to the URL you hand it, so an n8n Webhook node can receive it without anyone opening the crowd.dev interface.

• Trigger: what will trigger an automation, either new_activity or new_member.
• URL: URL to POST webhook data to, typically the production URL of a Webhook node in n8n.

Removes one automation from the tenant. Nothing is picked by name here, so the workflow has to be holding the identifier before this node runs.

• ID: the ID of the automation, typically {{ $json.id }} taken from a List step filtered just before.

Reads a single automation back. That is how a workflow checks that the URL and the Trigger stored on the tenant still match what it expects to receive.

• ID: the ID of the automation you want to read.

Returns every automation on the tenant, with no parameter to fill at all. That makes it the easiest node to run first when you want to confirm the credential works, because a failure can only come from the connection.

Rewrites an automation in place. Both the event and the destination are required, so the call carries the pair even when only one of them actually changes.

• ID: the ID of the automation to modify.
• Trigger: what will trigger an automation, new_activity or new_member.
• URL: URL to POST webhook data to, here the new destination.

Upserts a community member. crowd.dev checks whether that handle already exists on that platform: if it does, the record is updated, if not, it is created.

• Platform: platform for which to check member existence.
• Username: username of the member in platform, the value that decides between create and update.
• Emails: email addresses of the member, from Additional Options, worth filling when the record has to be matched with a CRM later.

Erases a member record from the tenant. It takes the identifier and nothing else, so a workflow that starts from an email address resolves the member first and deletes second.

• ID: the ID of the member to remove.

Looks a member up by identifier and hands the record to the next node. It is the step that turns an ID floating around in your data into something a message can actually name.

• ID: the ID of the member, often {{ $json.id }} passed along from an earlier crowd.dev node.

Edits a member you already have the ID for. The platform and username pair travels with the call, which keeps the record anchored to the same identity while the rest moves.

• ID: the ID of the member being edited.
• Username: username of the member in platform, required even when the change targets something else entirely.
• Organizations: organizations associated with the member; if the organization does not exist, it will be created.

Drops a free-text note into crowd.dev. No field is required on this one, so an empty note goes through: fill Body unless you are only testing the wiring.

• Body: the body of the note, the text itself.

Removes a note by identifier. It earns its place the day a workflow writes notes automatically and you need a matching cleanup path for the ones written by mistake.

• ID: the ID of the note to delete.

Fetches one note so its text can be read inside the workflow rather than in the crowd.dev interface. Everything downstream then works on the content, not on a reference to it.

• ID: the ID of the note you want to read.

Replaces the text of an existing note. The identifier is required, the text is not, which means the call goes through even when nothing new is sent with it.

• ID: the ID of the note to rewrite.
• Body: the body of the note, here the new text.

Adds a company to crowd.dev. Only the name is required, and the optional fields are what turn the row into a record worth opening later.

• Name: the name of the organization, the single required field.
• Url: the URL of the organization, handy when several records share a name.
• Employees: the number of employees of the organization, a number and not a range.

Takes a company out of the tenant. The call needs its identifier, so the workflow reads before it writes and never guesses from the name on screen.

• ID: the ID of the organization to delete.

Reads one company record back. Where Find a member returns a person, this returns the account around them, which is usually what a routing rule needs to decide anything.

• ID: the ID of the organization, usually carried over from the member record that references it.

Refreshes a company that already exists. Name is required next to the identifier, so send the current name back when the point of the call is elsewhere.

• ID: the ID of the organization being edited.
• Description: a short description of the organization, from Additional Options.
• Members: members associated with the organization, each element being the ID of the member.

Opens a task in crowd.dev. Nothing is required here, which is convenient in a branch, and also means a task with no name is accepted without complaint.

• Name: the name of the task, from Additional Options.
• Status: the status of the task, a free string your team has to agree on once.
• Assigneess: users assigned with the task, each element being the ID of the user, spelled that way in the node.

Removes a task from the tenant. The identifier is the only input, so keep it somewhere the workflow can reach when the task was created earlier in the same run.

• ID: the ID of the task to delete.

Returns a single task. Handy as the read step in front of a decision node, when the branch depends on where that task currently stands.

• ID: the ID of the task to read.

Changes a task in place, most often its status. Everything except the identifier sits in Additional Options, so the call carries only what actually moves.

• ID: the ID of the task to modify.
• Status: the status of the task, the field a workflow moves most often.
• Members: members associated with the task, each element being the ID of the member.