Make.com can create Todoist tasks automatically on selected days, but the important design decision is not the Todoist module itself. It is the rule that determines whether today is an allowed day. A reliable scenario runs on a schedule, evaluates the current date in the correct timezone, and creates a task only when the day passes that rule.
This is useful when Todoist’s basic recurring-task options do not express the operating rule clearly, such as creating a task every weekday, every day except Monday and Friday, or every working day with additional holiday exceptions. The safest pattern is to separate the daily trigger from the decision to create a task.
In practice, that means using a scheduled Make.com scenario, a date value, a filter or router, and a Todoist action on the allowed path. Before activating it, test both outcomes: a day when a task should be created and a day when the scenario should deliberately do nothing.
The operating model: trigger, decide, then act
A day-based Todoist automation has three distinct responsibilities:
- Trigger: Make.com starts the scenario at a defined time.
- Decision: the scenario determines whether the current date is included by the rule.
- Action: Todoist receives a new task only when the decision is positive.
Keeping these responsibilities separate makes the workflow easier to inspect and change. The scheduler should not contain the business rule, and the Todoist module should not be responsible for deciding which days are valid.
A scheduled automation should run every day when the rule needs daily evaluation, but it should create work only when the business condition is true.
For example, “every day except Saturday and Sunday” is an inclusion rule for Monday through Friday. “Every day except Monday and Friday” is an exclusion rule. Both can work, but an explicit inclusion rule is often easier to understand when the valid days are known and limited.
Define the day rule before building the scenario
Write the scheduling rule in plain language before opening Make.com. This prevents a common failure mode in which filters are added before anyone has agreed what the filter is meant to represent.
Use an inclusion rule when valid days are clearer
An inclusion rule answers: “Which weekdays are allowed to create the task?” Examples include:
- Monday through Friday only.
- Tuesday and Thursday only.
- Every weekday except Friday.
This approach is generally easier to audit because the route passes only when the weekday belongs to the approved set.
Use an exclusion rule when exceptions are clearer
An exclusion rule answers: “Which weekdays must be skipped?” Examples include:
- Every day except Sunday.
- Every day except Monday and Friday.
- Every day except the weekend.
Whichever form you choose, document the weekday numbering or text values used by the date function. Do not assume that a value of 1 always means Monday in every function or configuration. Confirm the output in a test run and use the scenario timezone consistently.
A filter that is logically correct but based on an unverified weekday convention can create tasks on the wrong days without producing an obvious error.
Build the Make.com scenario
1. Schedule the scenario to run daily
Create a new Make.com scenario and configure its schedule to run once each day at the time you want the task to be created. The schedule is the evaluation point, not the final decision.
Choose a time that works with the intended date. A scenario running shortly after midnight may evaluate a different date from the one a person considers the start of their working day. If the task is intended to represent work for the current business day, select a time and timezone that match that operating practice.
2. Capture the current date and weekday
Add a date or tools step after the scheduler to make the date value explicit. You need a value that can be compared in a filter. Depending on the Make.com functions available in your scenario, this may be a weekday number or a formatted weekday value.
Use one consistent source for the date. Avoid calculating the weekday from one timestamp while assigning the Todoist due date from another timestamp that could fall on a different calendar day. This can happen around midnight or when the Make.com account timezone differs from the user’s local timezone.
During setup, run the scenario once and inspect the date output. Record what the weekday value means, then build the filter from that verified value rather than relying on an example copied from another workflow.
3. Add a filter or router for the decision
For a simple rule, a single filter before the Todoist module may be enough. For example, a filter can allow only the weekday values that represent Monday through Friday. A router becomes useful when different valid days need different task content or when you want a separate branch for logging, exception handling, or another action.
Keep the allowed route visibly connected to the Todoist module. A route that represents an excluded day does not need a Todoist module. When the filter fails, the scenario should stop for that route without creating a placeholder task.
One allowed path
Use one filter and one Todoist action when every allowed day creates the same type of task.
Multiple routes
Use a router when different weekdays need different task titles, projects, priorities, or downstream actions.
4. Configure the Todoist action
Add the Todoist task creation module after the allowed filter or on the allowed router route. Select the intended project and map the task content. Add a due date only if the workflow needs one, and make sure the due date is derived from the same date context used for the weekday decision.
Use a stable task title when the task represents the same recurring responsibility. If the title includes the date, format the date deliberately so people can recognize which business day the task belongs to. Labels, priority, and section should support how the task is managed after creation, not simply add fields because they are available.
Prevent common scheduling failures
Timezone mismatches
Timezone problems are among the most confusing failures in date-based automation. The scenario may run on Tuesday according to the Make.com account while the task is dated Monday according to the user’s local timezone. Check the scenario timezone, the timestamp being formatted, and the timezone expected by the Todoist action.
Test the workflow near a date boundary if the schedule runs around midnight. A short operational note describing the chosen timezone can prevent later changes from silently altering the result.
Duplicate tasks after reruns
A daily scenario can create duplicates if it is manually rerun, retried after an uncertain response, or activated more than once. The weekday filter only answers whether the task is allowed. It does not answer whether the task has already been created.
If duplicate prevention matters, define an idempotency rule before expanding the scenario. For example, the workflow may need to check for an existing task with a predictable title and date before creating another one. The exact implementation depends on the available Todoist and Make.com operations, so test the behavior rather than assuming a retry is safe.
Changing the rule without reviewing history
If the rule changes from weekdays only to every day except Friday, review what existing tasks represent. A new automation rule may affect future task creation, but it does not automatically clean up tasks created under the old rule. Treat the schedule definition and existing Todoist data as separate operational decisions.
A filter controls eligibility. It does not automatically provide deduplication, date governance, or cleanup of tasks created in the past.
Test the scenario as a decision table
Do not test only the day on which you happen to build the scenario. Test the decision logic against representative inputs. A simple table can include:
- An allowed weekday creates exactly one expected Todoist task.
- An excluded weekday creates no Todoist task.
- The weekday value is confirmed for the configured timezone.
- The Todoist project, section, title, and due date are correct.
- A rerun or retry does not create an unexpected duplicate, or the risk is documented.
- A future rule change can be made without rebuilding unrelated parts of the scenario.
Use Make.com’s run-once capability to inspect the values passed between modules. If you need to test another weekday, temporarily use a controlled date value or adjust the filter for testing, then restore the production condition before activation. Keep test data distinct from real operational tasks where possible.
Extend the workflow only when the rule requires it
Once the basic scenario is reliable, you can add exceptions. A holiday calendar, for example, introduces another decision: the weekday may be valid, but the date may still be excluded. In that design, the weekday check and holiday check should remain understandable as separate conditions.
Different tasks per weekday can also justify separate router routes. Monday might create a planning task while Friday creates a review task. That is a meaningful difference in business state. Creating separate routes merely because a router is available usually increases maintenance without improving the workflow.
For broader operating systems, task creation may be only one part of a larger process involving CRM records, approvals, reporting, or ownership. In those cases, the workflow should be designed around the business state that needs to change, not around the number of apps that can be connected. ConsultEvo’s systems, CRM, automation and AI implementation services reflect this process-first approach.
For examples of connected operational systems and automation work, the ConsultEvo client work portfolio provides relevant context without changing the narrow Todoist scheduling pattern described here.
When this pattern is the right fit
A scheduled Make.com scenario is a good fit when the task must be evaluated against a calendar rule, when the rule may change, or when creation needs to connect with other systems. It may be unnecessary when Todoist’s native recurring-task behavior already expresses the requirement clearly and no additional automation is needed.
The decision should be based on operational complexity. Use the simpler native option when it is sufficient. Use Make.com when the workflow needs conditional logic, external exceptions, data from another system, or a visible handoff beyond Todoist.
More automation is not automatically better. The best design is the smallest workflow that represents the real scheduling rule and remains easy for someone else to verify.
A practical operating sequence
- Write the allowed and excluded days in plain language.
- Choose the timezone and date source.
- Run the date step and verify the weekday output.
- Apply an inclusion or exclusion filter.
- Create the Todoist task only on the passing route.
- Test allowed days, excluded days, boundaries, and reruns.
- Document the rule and activate the scenario.
This sequence keeps the automation understandable. When a task appears on the wrong day, you can inspect the trigger, date value, filter, or Todoist action instead of troubleshooting an opaque chain of modules.
Frequently asked questions
Can Make.com create a Todoist task only on weekdays?
Yes. Schedule the scenario daily, determine the weekday from a verified date value, and place a filter before the Todoist action that allows only the weekday values you want.
Should I use a router or a filter for weekday scheduling?
Use a single filter when all allowed days create the same task. Use a router when different weekdays need different task content, projects, priorities, or follow-up actions.
Why are Todoist tasks appearing on the wrong day?
Check the scenario timezone, the timestamp used to calculate the weekday, and the weekday numbering or text convention returned by the date function. Date boundaries can expose timezone mismatches.
How can I avoid duplicate Todoist tasks when a Make.com scenario is rerun?
Define a duplicate-prevention rule, such as checking for an existing task with a predictable title and date before creating another one. Test retries and manual reruns rather than assuming they are safe.
Can this workflow skip holidays as well as weekdays?
Yes. Add a separate holiday check after the weekday decision or combine both conditions in a clearly documented rule. Keep weekday eligibility and holiday exceptions distinct so the logic remains maintainable.
Make the scheduling rule reliable
If a Todoist automation has grown beyond a simple weekday filter, ConsultEvo can help clarify the process, define ownership, and build a maintainable Make.com workflow.
