How to Automate Webflow Comments with Make.com

What a Webflow comments automation should accomplish

A Webflow comments workflow should convert feedback into an accountable next step. A notification alone may tell someone that a comment exists, but it does not necessarily create ownership, preserve context, or show whether the issue has been handled.

Before building a scenario, define the operational outcome. For example, a new comment might require a task for a content editor, a comment from a client might need a review notification, and a resolved comment might update a delivery record. These are different events with different responsibilities, even if they originate in the same Webflow project.

Make.com is useful as an orchestration layer because it can receive an event, apply conditions, map fields, and pass information to other applications. The exact Webflow modules and event options can vary by connector version and account setup, so confirm the available trigger and returned fields before designing the full scenario.

Define the business logic before opening Make.com

The most common design mistake is starting with the available modules instead of the required workflow. Begin with a simple event-to-outcome table:

• Event: a new comment is created. Outcome: the responsible reviewer receives an alert or a task.
• Event: a comment requires a content change. Outcome: the work enters the correct editing queue with the source URL and comment text.
• Event: a comment is resolved. Outcome: the related task or review record moves to the next meaningful state.

Then answer four diagnostic questions:

• What type of comment should start the workflow?
• Who owns the next action?
• What information is required to complete that action?
• What should happen if the comment is incomplete, duplicated, or not assigned?

These questions prevent a common failure mode: automating activity without automating responsibility. If the scenario creates a task but does not assign an owner, the manual work has only moved to another application.

Set up the Webflow to Make.com connection

Create a new scenario in Make.com and add the Webflow app as the starting point. Select the available trigger that matches the event you need, such as a new comment or a relevant update to comment activity. If the connector does not expose the event or fields required by your process, investigate the supported Webflow API or webhook approach before adding downstream actions.

When authorizing the connection, use an account with the appropriate access to the Webflow site and comments feature. Select the correct site or project, then capture a sample event. The sample is important because it shows which values Make.com can actually map, such as comment text, author details, page or element context, status, timestamps, and source links.

Do not assume that every field shown in Webflow will be available in the trigger output. Treat the sample payload as the contract for the next steps. If a required value is missing, solve that issue early rather than building the rest of the scenario around an unavailable field.

Build the scenario around a useful handoff

After the Webflow trigger, add only the actions that support the defined outcome. A practical first version might send a structured notification and create a task in a project workspace. If your team uses ClickUp, for example, the workflow could create a task containing the comment text, page link, author, review type, and a clear owner. The task should point back to Webflow as the source of truth for the visual context.

For task-based workflows, consider mapping:

• A concise task name based on the page and comment purpose.
• The complete comment text, without losing important context.
• A direct link to the relevant Webflow page or review location.
• The comment author and date, where available.
• A responsible person or team queue.
• A due date only when the business process defines how it should be calculated.
• A status that reflects the next action, such as “Needs review” or “In progress.”

For notifications, include enough context to make the message actionable. “A new Webflow comment was added” is weak. A better message identifies the page, explains the required action, names the owner, and links to the source.

For teams using ClickUp as the action system, review the relevant ClickUp consulting services guidance before deciding how Webflow feedback should map to spaces, lists, statuses, and custom fields.

Use filters and routes to protect signal quality

Not every Webflow comment should create the same downstream activity. Use Make.com filters or routers when different comment types have different owners or consequences.

• Route copy edits to the content queue.
• Route design issues to the design review queue.
• Send urgent or blocked items to a monitored team channel.
• Ignore test comments, internal notes, or events that do not require action.
• Handle resolved comments separately from newly created comments.

Keep the initial routing rules explicit. A small number of understandable routes is easier to maintain than a large scenario containing hidden exceptions. If the logic becomes difficult to explain, document the decision rules or split the process into separate scenarios.

Prevent duplicate tasks and unclear ownership

Comment workflows often run more than once because of polling schedules, retries, updates, or multiple related events. Design for idempotency where possible. Store or pass a stable comment identifier and check whether the corresponding task or record already exists before creating another one.

Also decide how ownership works when the source data does not name a responsible person. A safe fallback is a defined review queue rather than an unassigned task. The queue needs an owner for triage, otherwise the automation produces work that no one is expected to accept.

Use a simple ownership rule: every automated output must have either a named person, a named team, or a monitored queue. If none of these is available, the scenario should flag the exception rather than quietly continue.

Test the complete workflow before scheduling it

Test the scenario with representative examples rather than one ideal comment. Create or capture test events for a new comment, a comment requiring a different route, a resolved comment, a missing assignment, and a duplicate or repeated event.

1. Inspect the trigger: confirm that the intended Webflow event is received and that the important fields are present.
2. Check field mapping: verify that the comment, page, author, source link, and status reach the correct destination fields.
3. Test routing: confirm that each filter sends the event to the intended queue and that excluded events stop cleanly.
4. Test failure handling: decide what happens when a destination application rejects a task or a required field is empty.
5. Test duplicates: check that retries or repeated runs do not create multiple tasks for one comment.

Review the resulting task or message as a user would. If a person has to search through several applications to understand what the comment means, improve the payload before making the scenario live.

Operate and improve the scenario over time

A production automation needs more than a successful first run. Name the scenario according to its purpose, record the Webflow site and destinations it covers, and document the event, filters, owner rules, and exception path. Review Make.com execution history regularly, especially after changes to Webflow projects, task statuses, or team responsibilities.

Reporting should support a decision. Useful measures might include the number of comments entering each queue, unresolved items by age, failed scenario runs, or the proportion of comments that lack an owner. Avoid collecting data simply because it is available. Decide what action the report should support before adding another logging destination.

If the workflow grows to include CRM records, campaign information, or multiple delivery teams, document the system of record for each field. A central systems and automation implementation service can help when ownership, data structure, and integration logic need to be designed across more than one tool.

When Make.com is not the main solution

Make.com can connect applications, but it cannot resolve an undefined review process. If the team has no agreement about statuses, ownership, approval criteria, or the system of record, adding modules will make the ambiguity move faster.

In that situation, first define the review workflow and the business states it must represent. Then decide whether Make.com, a native Webflow capability, a project management platform, or a different integration method is the appropriate implementation. More tools do not automatically create a better operating system.

The strongest Webflow comments automation is usually a small, understandable workflow: capture meaningful feedback, route it to the right owner, preserve the source context, and update the next business state. Expand it only when the current process is reliable and the additional automation has a clear purpose.