From efbb34261dde3dafc8abf03437f6858d60ac7aa9 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 27 Nov 2025 14:10:03 +0100 Subject: [PATCH 01/13] Adding campaign republish behavior docs --- docs/campaigns/creating_campaigns.rst | 1 + docs/campaigns/managing_campaigns.rst | 103 +++++++++++++++++++++++++- docs/configuration/settings.rst | 10 +++ 3 files changed, 113 insertions(+), 1 deletion(-) diff --git a/docs/campaigns/creating_campaigns.rst b/docs/campaigns/creating_campaigns.rst index e98458fc..11bf2e9b 100644 --- a/docs/campaigns/creating_campaigns.rst +++ b/docs/campaigns/creating_campaigns.rst @@ -51,6 +51,7 @@ To begin creating Campaigns, perform the following steps: - **Category** - Choose a Category to assign your Campaign to. Categories help you organize your Campaigns. To learn more about creating and managing Categories, see :doc:`/categories/categories-overview`. - **Allow Contacts to restart the Campaign** - Click the toggle switch to allow Contacts to restart the Campaign if you're building a Campaign for a recurring message - for example birthdays, subscriptions - or transactional operations - for example activity notifications, updating data. Enabling this option allows Contacts to go through the same Campaign multiple times. +- **Campaign Republish Behaviour** - Configure how scheduled events with relative delays should behave when the Campaign is republished after being unpublished. You can override the global default setting for this specific Campaign. See :ref:`Campaign Republish Behavior` for more information about the available options. - **Active** - Click the toggle switch to turn the Campaign on or off. Ensure that you don't activate a Campaign until you're actually ready for it to go live. You can also schedule to activate or deactivate a Campaign at a future date by selecting a time and date. #. Click **Launch Campaign Builder** to start building your Campaign, and add at least one event. For information about how to use the Campaign Builder, see :doc:`/campaigns/campaign_builder`. diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index ed7b79a8..8c32874e 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -31,4 +31,105 @@ The **Conditions** tab displays a tabular list of all he conditions that you hav The **Contacts** tab displays a grid view of all the Contacts that you have added to your Campaign. -The **Recent Activity** panel on the right displays the recent activities that have taken place in the Campaign. \ No newline at end of file +The **Recent Activity** panel on the right displays the recent activities that have taken place in the Campaign. + +.. vale off + +.. _campaign republish behavior: + +Campaign Republish Behavior +*************************** + +.. vale on + +When you unpublish and then republish a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. + +.. note:: + This setting only affects events that use relative delays (interval-based scheduling). Events with absolute dates are not affected by this setting. + +Configuring republish behavior +=============================== + +You can configure the republish behavior at two levels: + +1. **Global default** - Set in Configuration > Campaign Settings > Campaign Republish Behaviour. This applies to all Campaigns unless overridden. +2. **Per Campaign** - Set when creating or editing a Campaign. This overrides the global default for that specific Campaign. + +Republish behavior options +========================== + +There are three options available for how scheduled events should behave after republishing: + +Count delay regardless of publish state +---------------------------------------- + +This is the default behavior. The original trigger date is used and unpublished time doesn't affect scheduling. + +**Example scenario:** + +- Campaign trigger date: January 1 +- Event delay: 10 days +- Calculated event date: January 11 +- Campaign unpublished: January 5 +- Campaign republished: January 7 + +**Result:** The event still executes on January 11, as originally scheduled. + +**When to use:** This option maintains the original scheduled timing, treating the Campaign's publish state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily unpublishing a Campaign shouldn't affect when events execute. + +Restart on republish +-------------------- + +The delay counter resets completely when you republish the Campaign. + +**Example scenario:** + +- Campaign trigger date: January 1 +- Event delay: 10 days +- Original calculated event date: January 11 +- Campaign unpublished: January 5 +- Campaign republished: January 7 + +**Result:** The event is rescheduled to execute 10 days after republishing, on January 17. + +**When to use:** This option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you unpublish a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. + +Count delay only while published +--------------------------------- + +Events only count days when the Campaign is published. Unpublished periods don't count toward the delay. + +**Example scenario:** + +- Campaign trigger date: January 1 +- Event delay: 10 days +- Original calculated event date: January 11 +- Campaign unpublished: January 5 (after 4 days published) +- Campaign republished: January 10 (after 5 days unpublished) + +**Result:** The event is rescheduled to execute on January 16. The 4 days while published (January 1-5) count toward the 10-day delay, leaving 6 more days needed after republishing (January 10 + 6 days = January 16). + +**When to use:** This option is ideal when you want precise control over the actual time Contacts spend in an active Campaign state. Use this for compliance scenarios, trial periods, or when you need to pause campaigns without affecting the intended engagement timeline. + +Viewing last publish date +========================= + +On the Campaign details page, you can see the **Last Publish Date** which indicates when the Campaign was most recently published. This date is used as the reference point for the "Restart on republish" option to recalculate scheduled event timings. + +Publishing and unpublishing Campaigns +====================================== + +When you publish or unpublish a Campaign, Mautic displays a confirmation message that shows the current republish behavior setting. This helps you understand what will happen to scheduled events before you confirm the action. + +.. warning:: + When you unpublish a Campaign, all processing of Contacts and Campaign events - including scheduled events - stops immediately. Scheduled events remain in the queue but won't execute until you republish the Campaign. + +.. note:: + The recalculation of scheduled events happens when the Campaign event log is being evaluated by the cron job, not at the moment you republish the Campaign. This means that if a recalculated trigger date is still in the past when evaluated, the event executes immediately. If it's in the future, the event is rescheduled accordingly. + +Tracking rescheduled events +=========================== + +Mautic records all changes to scheduled event trigger dates in the ``campaign_lead_event_log.metadata`` column. This audit trail allows you to investigate when and why events were rescheduled, providing transparency and helping with troubleshooting. + +You can view this information in the Contact's timeline under **Campaign Event Scheduled** entries, where rescheduled events show the updated trigger date and the reason for the change. \ No newline at end of file diff --git a/docs/configuration/settings.rst b/docs/configuration/settings.rst index 45ad3398..ffd8bcb8 100644 --- a/docs/configuration/settings.rst +++ b/docs/configuration/settings.rst @@ -158,6 +158,16 @@ Campaign settings * **Use summary statistics** - Improves performance when viewing a Campaign with thousands of events per day by using summarized data. When you first turn on this setting you need to run a :ref:`cron job` to summarize existing data. +* **Campaign Republish Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is republished after being unpublished for a while. This setting provides a global default that can be overridden per Campaign. See :ref:`Campaign Republish Behavior` for more information. + + Available options: + + - **Count delay regardless of publish state** - The original trigger date is used. Events execute based on the calendar days from when they were originally scheduled, regardless of whether the Campaign was published or unpublished during that period. This is the default behavior. + + - **Restart on republish** - The delay counter resets when the Campaign is republished. Events are rescheduled to execute the full delay period after the last publish date. + + - **Count delay only while published** - Events only count days when the Campaign is published. If the Campaign is unpublished, those days don't count toward the delay, and events are rescheduled accordingly when the Campaign is republished. + Optimal for Contact event scheduler =================================== From bf9ed15dc148faad5c4616f8706cafbfa645acf2 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Tue, 9 Dec 2025 09:59:53 +0100 Subject: [PATCH 02/13] Calud is fixing Vale errors --- docs/campaigns/managing_campaigns.rst | 26 +++++++++++++------------- docs/configuration/settings.rst | 2 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 8c32874e..6ae1bca7 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -37,15 +37,15 @@ The **Recent Activity** panel on the right displays the recent activities that h .. _campaign republish behavior: -Campaign Republish Behavior +Campaign republish behavior *************************** .. vale on -When you unpublish and then republish a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. +When you Unpublish and then republish a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. .. note:: - This setting only affects events that use relative delays (interval-based scheduling). Events with absolute dates are not affected by this setting. + This setting only affects events that use relative delays (interval-based scheduling). Events with absolute dates aren't affected by this setting. Configuring republish behavior =============================== @@ -73,9 +73,9 @@ This is the default behavior. The original trigger date is used and unpublished - Campaign unpublished: January 5 - Campaign republished: January 7 -**Result:** The event still executes on January 11, as originally scheduled. +**Result:** the event still executes on January 11, as originally scheduled. -**When to use:** This option maintains the original scheduled timing, treating the Campaign's publish state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily unpublishing a Campaign shouldn't affect when events execute. +**When to use:** this option maintains the original scheduled timing, treating the Campaign's publish state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily using Unpublish on a Campaign shouldn't affect when events execute. Restart on republish -------------------- @@ -90,9 +90,9 @@ The delay counter resets completely when you republish the Campaign. - Campaign unpublished: January 5 - Campaign republished: January 7 -**Result:** The event is rescheduled to execute 10 days after republishing, on January 17. +**Result:** the event is rescheduled to execute 10 days after republishing, on January 17. -**When to use:** This option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you unpublish a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. +**When to use:** this option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you Unpublish a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. Count delay only while published --------------------------------- @@ -107,25 +107,25 @@ Events only count days when the Campaign is published. Unpublished periods don't - Campaign unpublished: January 5 (after 4 days published) - Campaign republished: January 10 (after 5 days unpublished) -**Result:** The event is rescheduled to execute on January 16. The 4 days while published (January 1-5) count toward the 10-day delay, leaving 6 more days needed after republishing (January 10 + 6 days = January 16). +**Result:** the event is rescheduled to execute on January 16. The 4 days while published (January 1-5) count toward the 10-day delay, leaving 6 more days needed after republishing (January 10 + 6 days = January 16). -**When to use:** This option is ideal when you want precise control over the actual time Contacts spend in an active Campaign state. Use this for compliance scenarios, trial periods, or when you need to pause campaigns without affecting the intended engagement timeline. +**When to use:** this option is ideal when you want precise control over the actual time Contacts spend in an active Campaign state. Use this for compliance scenarios, trial periods, or when you need to pause Campaigns without affecting the intended engagement timeline. Viewing last publish date ========================= On the Campaign details page, you can see the **Last Publish Date** which indicates when the Campaign was most recently published. This date is used as the reference point for the "Restart on republish" option to recalculate scheduled event timings. -Publishing and unpublishing Campaigns +Publish and Unpublish Campaigns ====================================== -When you publish or unpublish a Campaign, Mautic displays a confirmation message that shows the current republish behavior setting. This helps you understand what will happen to scheduled events before you confirm the action. +When you publish or Unpublish a Campaign, Mautic displays a confirmation message that shows the current republish behavior setting. This helps you understand what happens to scheduled events before you confirm the action. .. warning:: - When you unpublish a Campaign, all processing of Contacts and Campaign events - including scheduled events - stops immediately. Scheduled events remain in the queue but won't execute until you republish the Campaign. + When you Unpublish a Campaign, all processing of Contacts and Campaign events - including scheduled events - stops immediately. Scheduled events remain in the queue but won't execute until you republish the Campaign. .. note:: - The recalculation of scheduled events happens when the Campaign event log is being evaluated by the cron job, not at the moment you republish the Campaign. This means that if a recalculated trigger date is still in the past when evaluated, the event executes immediately. If it's in the future, the event is rescheduled accordingly. + The recalculation of scheduled events happens when the Campaign event log is being evaluated by the Cron job, not at the moment you republish the Campaign. This means that if a recalculated trigger date is still in the past when evaluated, the event executes immediately. If it's in the future, the event is rescheduled accordingly. Tracking rescheduled events =========================== diff --git a/docs/configuration/settings.rst b/docs/configuration/settings.rst index ffd8bcb8..8caa39d7 100644 --- a/docs/configuration/settings.rst +++ b/docs/configuration/settings.rst @@ -156,7 +156,7 @@ Campaign settings * **Use date range for all views** - When viewing a Campaign, the date range of actions, conditions, decisions, and Contacts displayed in the tabs, Mautic uses this date range by default. -* **Use summary statistics** - Improves performance when viewing a Campaign with thousands of events per day by using summarized data. When you first turn on this setting you need to run a :ref:`cron job` to summarize existing data. +* **Use summary statistics** - Improves performance when viewing a Campaign with thousands of events per day by using summarized data. When you first turn on this setting you need to run a :ref:`Cron job` to summarize existing data. * **Campaign Republish Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is republished after being unpublished for a while. This setting provides a global default that can be overridden per Campaign. See :ref:`Campaign Republish Behavior` for more information. From bf4fb31fe0969e94c5f0f391650c78c0a3771410 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Tue, 9 Dec 2025 17:14:08 +0100 Subject: [PATCH 03/13] Rewording to fit the UI changes --- docs/campaigns/creating_campaigns.rst | 2 +- docs/campaigns/managing_campaigns.rst | 78 ++++++++++++++------------- docs/configuration/settings.rst | 8 +-- 3 files changed, 45 insertions(+), 43 deletions(-) diff --git a/docs/campaigns/creating_campaigns.rst b/docs/campaigns/creating_campaigns.rst index 11bf2e9b..d5d1ed2c 100644 --- a/docs/campaigns/creating_campaigns.rst +++ b/docs/campaigns/creating_campaigns.rst @@ -51,7 +51,7 @@ To begin creating Campaigns, perform the following steps: - **Category** - Choose a Category to assign your Campaign to. Categories help you organize your Campaigns. To learn more about creating and managing Categories, see :doc:`/categories/categories-overview`. - **Allow Contacts to restart the Campaign** - Click the toggle switch to allow Contacts to restart the Campaign if you're building a Campaign for a recurring message - for example birthdays, subscriptions - or transactional operations - for example activity notifications, updating data. Enabling this option allows Contacts to go through the same Campaign multiple times. -- **Campaign Republish Behaviour** - Configure how scheduled events with relative delays should behave when the Campaign is republished after being unpublished. You can override the global default setting for this specific Campaign. See :ref:`Campaign Republish Behavior` for more information about the available options. +- **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays should behave when the Campaign is reactivated after being deactivated. You can override the global default setting for this specific Campaign. See :ref:`Campaign Reactivation Behaviour` for more information about the available options. - **Active** - Click the toggle switch to turn the Campaign on or off. Ensure that you don't activate a Campaign until you're actually ready for it to go live. You can also schedule to activate or deactivate a Campaign at a future date by selecting a time and date. #. Click **Launch Campaign Builder** to start building your Campaign, and add at least one event. For information about how to use the Campaign Builder, see :doc:`/campaigns/campaign_builder`. diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 6ae1bca7..fb5aa167 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -35,97 +35,99 @@ The **Recent Activity** panel on the right displays the recent activities that h .. vale off -.. _campaign republish behavior: +.. _campaign reactivate behavior: -Campaign republish behavior -*************************** +Campaign reactivation behaviour +******************************** .. vale on -When you Unpublish and then republish a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. +When you deactivate and then reactivate a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. .. note:: This setting only affects events that use relative delays (interval-based scheduling). Events with absolute dates aren't affected by this setting. -Configuring republish behavior -=============================== +Configuring reactivation behaviour +=================================== -You can configure the republish behavior at two levels: +You can configure the reactivation behaviour at two levels: -1. **Global default** - Set in Configuration > Campaign Settings > Campaign Republish Behaviour. This applies to all Campaigns unless overridden. +1. **Global default** - Set in Configuration > Campaign Settings > Campaign Reactivation Behaviour. This applies to all Campaigns unless overridden. 2. **Per Campaign** - Set when creating or editing a Campaign. This overrides the global default for that specific Campaign. -Republish behavior options -========================== +Reactivation behaviour options +=============================== -There are three options available for how scheduled events should behave after republishing: +There are three options available for how scheduled events should behave after reactivation: -Count delay regardless of publish state ----------------------------------------- +Count delay regardless of activation statetate +------------------------------------------- -This is the default behavior. The original trigger date is used and unpublished time doesn't affect scheduling. +This is the default behaviour. The original trigger date is used and inactive time doesn't affect scheduling. **Example scenario:** - Campaign trigger date: January 1 - Event delay: 10 days - Calculated event date: January 11 -- Campaign unpublished: January 5 -- Campaign republished: January 7 +- Campaign deactivated: January 5 +- Campaign reactivated: January 7 **Result:** the event still executes on January 11, as originally scheduled. -**When to use:** this option maintains the original scheduled timing, treating the Campaign's publish state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily using Unpublish on a Campaign shouldn't affect when events execute. +**When to use:** this option maintains the original scheduled timing, treating the Campaign's activation state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily deactivating a Campaign shouldn't affect when events execute. -Restart on republish --------------------- +Restart on reactivation +--------------------- -The delay counter resets completely when you republish the Campaign. +The delay counter resets completely when you reactivate the Campaign. **Example scenario:** - Campaign trigger date: January 1 - Event delay: 10 days - Original calculated event date: January 11 -- Campaign unpublished: January 5 -- Campaign republished: January 7 +- Campaign deactivated: January 5 +- Campaign reactivated: January 7 -**Result:** the event is rescheduled to execute 10 days after republishing, on January 17. +**Result:** the event is rescheduled to execute 10 days after reactivation, on January 17. -**When to use:** this option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you Unpublish a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. +**When to use:** this option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you deactivate a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. -Count delay only while published ---------------------------------- +Count delay only while active +------------------------------ -Events only count days when the Campaign is published. Unpublished periods don't count toward the delay. +Events only count days when the Campaign is active. Inactive periods don't count toward the delay. **Example scenario:** - Campaign trigger date: January 1 - Event delay: 10 days - Original calculated event date: January 11 -- Campaign unpublished: January 5 (after 4 days published) -- Campaign republished: January 10 (after 5 days unpublished) +- Campaign deactivated: January 5 (after 4 days active) +- Campaign reactivated: January 10 (after 5 days inactive) -**Result:** the event is rescheduled to execute on January 16. The 4 days while published (January 1-5) count toward the 10-day delay, leaving 6 more days needed after republishing (January 10 + 6 days = January 16). +**Result:** the event is rescheduled to execute on January 16. The 4 days while active (January 1-5) count toward the 10-day delay, leaving 6 more days needed after reactivation (January 10 + 6 days = January 16). **When to use:** this option is ideal when you want precise control over the actual time Contacts spend in an active Campaign state. Use this for compliance scenarios, trial periods, or when you need to pause Campaigns without affecting the intended engagement timeline. -Viewing last publish date -========================= +Viewing last activation date +============================= + +On the Campaign details page, you can see the **Last Publish Date** which indicates when the Campaign was most recently activated. This date is used as the reference point for the "Restart on reactivate" option to recalculate scheduled event timings. -On the Campaign details page, you can see the **Last Publish Date** which indicates when the Campaign was most recently published. This date is used as the reference point for the "Restart on republish" option to recalculate scheduled event timings. +Activate and deactivate Campaigns +================================== -Publish and Unpublish Campaigns -====================================== +When you activate or deactivate a Campaign, Mautic displays a confirmation message that shows the current reactivation behaviour setting. This helps you understand what happens to scheduled events before you confirm the action. -When you publish or Unpublish a Campaign, Mautic displays a confirmation message that shows the current republish behavior setting. This helps you understand what happens to scheduled events before you confirm the action. +For example: "All scheduled events execute according to the reactivation behaviour setting. Currently set to: Count delay regardless of activation state" .. warning:: - When you Unpublish a Campaign, all processing of Contacts and Campaign events - including scheduled events - stops immediately. Scheduled events remain in the queue but won't execute until you republish the Campaign. + When you deactivate a Campaign, all processing of Contacts and Campaign events - including scheduled events - stops immediately. Scheduled events remain in the queue but won't execute until you reactivate the Campaign. .. note:: - The recalculation of scheduled events happens when the Campaign event log is being evaluated by the Cron job, not at the moment you republish the Campaign. This means that if a recalculated trigger date is still in the past when evaluated, the event executes immediately. If it's in the future, the event is rescheduled accordingly. + The recalculation of scheduled events happens when the Campaign event log is being evaluated by the Cron job, not at the moment you reactivate the Campaign. This means that if a recalculated trigger date is still in the past when evaluated, the event executes immediately. If it's in the future, the event is rescheduled accordingly. Tracking rescheduled events =========================== diff --git a/docs/configuration/settings.rst b/docs/configuration/settings.rst index 8caa39d7..5632ba34 100644 --- a/docs/configuration/settings.rst +++ b/docs/configuration/settings.rst @@ -158,15 +158,15 @@ Campaign settings * **Use summary statistics** - Improves performance when viewing a Campaign with thousands of events per day by using summarized data. When you first turn on this setting you need to run a :ref:`Cron job` to summarize existing data. -* **Campaign Republish Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is republished after being unpublished for a while. This setting provides a global default that can be overridden per Campaign. See :ref:`Campaign Republish Behavior` for more information. +* **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is reactivated after being deactivated for a while. This setting provides a global default that can be overridden per Campaign. This setting affects how the :ref:`Campaign cron jobs` schedule events. See :ref:`Campaign Reactivation Behaviour` for more information. Available options: - - **Count delay regardless of publish state** - The original trigger date is used. Events execute based on the calendar days from when they were originally scheduled, regardless of whether the Campaign was published or unpublished during that period. This is the default behavior. + - **Count delay regardless of activation state** - The original trigger date is used. Events execute based on the calendar days from when they were originally scheduled, regardless of whether the Campaign was active or inactive during that period. This is the default behaviour. - - **Restart on republish** - The delay counter resets when the Campaign is republished. Events are rescheduled to execute the full delay period after the last publish date. + - **Restart on reactivation** - The delay counter resets when the Campaign is reactivated. Events are rescheduled to execute the full delay period after the last activation date. - - **Count delay only while published** - Events only count days when the Campaign is published. If the Campaign is unpublished, those days don't count toward the delay, and events are rescheduled accordingly when the Campaign is republished. + - **Count delay only while active** - Events only count days when the Campaign is active. If the Campaign is inactive, those days don't count toward the delay, and events are rescheduled accordingly when the Campaign is reactivated. Optimal for Contact event scheduler =================================== From 3e0299f6f237f22fcd70ffb55e440ab45ca3ee7e Mon Sep 17 00:00:00 2001 From: John Linhart Date: Tue, 9 Dec 2025 17:30:08 +0100 Subject: [PATCH 04/13] Vale fixes --- docs/campaigns/managing_campaigns.rst | 2 +- docs/configuration/settings.rst | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index fb5aa167..d882fea6 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -60,7 +60,7 @@ Reactivation behaviour options There are three options available for how scheduled events should behave after reactivation: -Count delay regardless of activation statetate +Count delay regardless of activation state ------------------------------------------- This is the default behaviour. The original trigger date is used and inactive time doesn't affect scheduling. diff --git a/docs/configuration/settings.rst b/docs/configuration/settings.rst index 5632ba34..5ce4ed04 100644 --- a/docs/configuration/settings.rst +++ b/docs/configuration/settings.rst @@ -158,7 +158,7 @@ Campaign settings * **Use summary statistics** - Improves performance when viewing a Campaign with thousands of events per day by using summarized data. When you first turn on this setting you need to run a :ref:`Cron job` to summarize existing data. -* **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is reactivated after being deactivated for a while. This setting provides a global default that can be overridden per Campaign. This setting affects how the :ref:`Campaign cron jobs` schedule events. See :ref:`Campaign Reactivation Behaviour` for more information. +* **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays in the middle of the workflow should behave when the Campaign is reactivated after being deactivated for a while. This setting provides a global default that can be overridden per Campaign. This setting affects how the :ref:`Campaign Cron jobs` schedule events. See :ref:`Campaign Reactivation Behaviour` for more information. Available options: @@ -293,7 +293,7 @@ The table below lists available transport Plugins created for Mautic to include Configuring the Queue ===================== -The system can either send Emails immediately or queue them for processing in batches by a :doc:`cron job `. Documentation relating to configuring the queue is in the :doc:`queue ` section. +The system can either send Emails immediately or queue them for processing in batches by a :doc:`Cron job `. Documentation relating to configuring the queue is in the :doc:`queue ` section. Immediate delivery ------------------ @@ -303,13 +303,13 @@ This is the default means of delivery. As soon as an action in Mautic triggers a Queued delivery --------------- -Mautic works most effectively with high send volumes if you use the queued delivery method. Mautic stores the Email in the configured spool directory until the execution of the command to process the queue. Set up a :doc:`cron job ` at the desired interval to run the command: +Mautic works most effectively with high send volumes if you use the queued delivery method. Mautic stores the Email in the configured spool directory until the execution of the command to process the queue. Set up a :doc:`Cron job ` at the desired interval to run the command: .. code-block:: shell php /path/to/mautic/bin/console messenger:consume email -Some hosts may have limits on the number of Emails sent during a specified time frame and/or limit the execution time of a script. If that's the case for you, or if you just want to moderate batch processing, you can configure batch numbers and time limits in Mautic's Configuration. See the :doc:`cron job documentation ` for more specifics. +Some hosts may have limits on the number of Emails sent during a specified time frame and/or limit the execution time of a script. If that's the case for you, or if you just want to moderate batch processing, you can configure batch numbers and time limits in Mautic's Configuration. See the :doc:`Cron job documentation ` for more specifics. Mail send settings @@ -477,7 +477,7 @@ Import settings :width: 600 :alt: Screenshot showing Import Settings Configuration in Mautic -* **Automatically import in the background if the CSV has more rows than defined** - If there are more than the specified number of rows in an import file, the CSV automatically sets to import in the background which requires a :ref:`cron job` to trigger. Set to 0 if you want to always import files in the background recommended for performance optimization. +* **Automatically import in the background if the CSV has more rows than defined** - If there are more than the specified number of rows in an import file, the CSV automatically sets to import in the background which requires a :ref:`Cron job` to trigger. Set to 0 if you want to always import files in the background recommended for performance optimization. Export settings =============== @@ -495,7 +495,7 @@ Segment settings :width: 600 :alt: Screenshot showing Segment Settings Configuration in Mautic -* **Show warning if Segment hasn't been rebuilt for X hours** - Every time a :ref:`cron jobs` runs, Segments are rebuilt. If there is an error that prevents a Segment from rebuilding, Mautic displays a warning message. This field allows you to configure the allowable length of time between rebuilds, after which the warning message appears. +* **Show warning if Segment hasn't been rebuilt for X hours** - Every time a :ref:`Cron jobs` runs, Segments are rebuilt. If there is an error that prevents a Segment from rebuilding, Mautic displays a warning message. This field allows you to configure the allowable length of time between rebuilds, after which the warning message appears. Company settings **************** @@ -778,7 +778,7 @@ Webhook settings :width: 600 :alt: Screenshot showing Webhook Settings Configuration in Mautic -* **Queue Mode** - Select how to process Webhook events. The process immediately executes the Webhook event as soon as it arrives. The queue mode improves performance by only adding the event to the queue and requires processing by a :ref:`cron command`. +* **Queue Mode** - Select how to process Webhook events. The process immediately executes the Webhook event as soon as it arrives. The queue mode improves performance by only adding the event to the queue and requires processing by a :ref:`Cron command`. * **Order of the queued events** - Process the events in chronological or reverse chronological order if a Webhook has a queue of multiple events. From 298b8069a48e52193e612ab98dc084b2ad8f4660 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:54:43 +0100 Subject: [PATCH 05/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/creating_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/creating_campaigns.rst b/docs/campaigns/creating_campaigns.rst index d5d1ed2c..38128b35 100644 --- a/docs/campaigns/creating_campaigns.rst +++ b/docs/campaigns/creating_campaigns.rst @@ -51,7 +51,7 @@ To begin creating Campaigns, perform the following steps: - **Category** - Choose a Category to assign your Campaign to. Categories help you organize your Campaigns. To learn more about creating and managing Categories, see :doc:`/categories/categories-overview`. - **Allow Contacts to restart the Campaign** - Click the toggle switch to allow Contacts to restart the Campaign if you're building a Campaign for a recurring message - for example birthdays, subscriptions - or transactional operations - for example activity notifications, updating data. Enabling this option allows Contacts to go through the same Campaign multiple times. -- **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays should behave when the Campaign is reactivated after being deactivated. You can override the global default setting for this specific Campaign. See :ref:`Campaign Reactivation Behaviour` for more information about the available options. +- **Campaign Reactivation Behaviour** - Configure how scheduled events with relative delays should behave when you reactivate a deactivated Campaign. You can override the global default setting for this specific Campaign. See :ref:`Campaign Reactivation Behaviour` for more information about the available options. - **Active** - Click the toggle switch to turn the Campaign on or off. Ensure that you don't activate a Campaign until you're actually ready for it to go live. You can also schedule to activate or deactivate a Campaign at a future date by selecting a time and date. #. Click **Launch Campaign Builder** to start building your Campaign, and add at least one event. For information about how to use the Campaign Builder, see :doc:`/campaigns/campaign_builder`. From 55ca3780d27491a57ab8f1dd0673034f88052a3f Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:14 +0100 Subject: [PATCH 06/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index d882fea6..492f3d53 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -38,7 +38,7 @@ The **Recent Activity** panel on the right displays the recent activities that h .. _campaign reactivate behavior: Campaign reactivation behaviour -******************************** +******************************* .. vale on From b3335837f007a834e4f8ea510d782eb4ca8e6e3c Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:22 +0100 Subject: [PATCH 07/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 492f3d53..cfff6405 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -45,7 +45,7 @@ Campaign reactivation behaviour When you deactivate and then reactivate a Campaign, Mautic provides control over how scheduled events with relative delays - such as "Send Email 5 days after joining" - should behave. This feature gives you flexibility in managing Campaign timing based on your specific use case. .. note:: - This setting only affects events that use relative delays (interval-based scheduling). Events with absolute dates aren't affected by this setting. + This setting only affects events that use relative delays - interval-based scheduling. Events with absolute dates aren't affected by this setting. Configuring reactivation behaviour =================================== From 0c5d939b8a66bdf5aba8c2fe05313fff12ae5430 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:30 +0100 Subject: [PATCH 08/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index cfff6405..4ba9014e 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -48,7 +48,7 @@ When you deactivate and then reactivate a Campaign, Mautic provides control over This setting only affects events that use relative delays - interval-based scheduling. Events with absolute dates aren't affected by this setting. Configuring reactivation behaviour -=================================== +================================== You can configure the reactivation behaviour at two levels: From a0dfa28e6fa95bdc7e3f3a3437a5d8dd68e62663 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:38 +0100 Subject: [PATCH 09/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 4ba9014e..8c26a7eb 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -56,7 +56,7 @@ You can configure the reactivation behaviour at two levels: 2. **Per Campaign** - Set when creating or editing a Campaign. This overrides the global default for that specific Campaign. Reactivation behaviour options -=============================== +============================== There are three options available for how scheduled events should behave after reactivation: From 5c96bceff8fed5a2608c7a7ce98738145554d4d7 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:47 +0100 Subject: [PATCH 10/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 8c26a7eb..56dee4ec 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -61,7 +61,7 @@ Reactivation behaviour options There are three options available for how scheduled events should behave after reactivation: Count delay regardless of activation state -------------------------------------------- +------------------------------------------ This is the default behaviour. The original trigger date is used and inactive time doesn't affect scheduling. From d423c8fb5ab78dd2e293a9e836037d4869fc1809 Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:55:55 +0100 Subject: [PATCH 11/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 56dee4ec..3a7ac05e 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -78,7 +78,7 @@ This is the default behaviour. The original trigger date is used and inactive ti **When to use:** this option maintains the original scheduled timing, treating the Campaign's activation state as irrelevant to the delay calculation. Use this when you want consistency with the original schedule, or when temporarily deactivating a Campaign shouldn't affect when events execute. Restart on reactivation ---------------------- +----------------------- The delay counter resets completely when you reactivate the Campaign. From 8c61628a1293cb77d0d2cf208c0cd83ba9381aef Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:56:04 +0100 Subject: [PATCH 12/13] Apply suggestion from @adiati98 Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 3a7ac05e..182ce59f 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -95,7 +95,7 @@ The delay counter resets completely when you reactivate the Campaign. **When to use:** this option is useful when you want to ensure all Contacts receive the full intended delay after any Campaign changes. For example, if you deactivate a Campaign to make significant updates and want everyone to experience the complete updated workflow timing. Count delay only while active ------------------------------- +----------------------------- Events only count days when the Campaign is active. Inactive periods don't count toward the delay. From b368a36daf7a6298840e1aec257a14fb4cc1e20a Mon Sep 17 00:00:00 2001 From: John Linhart Date: Thu, 18 Dec 2025 14:56:18 +0100 Subject: [PATCH 13/13] Apply suggestions from code review Co-authored-by: Ayu Adiati <45172775+adiati98@users.noreply.github.com> --- docs/campaigns/managing_campaigns.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/campaigns/managing_campaigns.rst b/docs/campaigns/managing_campaigns.rst index 182ce59f..6f306d9e 100644 --- a/docs/campaigns/managing_campaigns.rst +++ b/docs/campaigns/managing_campaigns.rst @@ -112,12 +112,12 @@ Events only count days when the Campaign is active. Inactive periods don't count **When to use:** this option is ideal when you want precise control over the actual time Contacts spend in an active Campaign state. Use this for compliance scenarios, trial periods, or when you need to pause Campaigns without affecting the intended engagement timeline. Viewing last activation date -============================= +============================ On the Campaign details page, you can see the **Last Publish Date** which indicates when the Campaign was most recently activated. This date is used as the reference point for the "Restart on reactivate" option to recalculate scheduled event timings. Activate and deactivate Campaigns -================================== +================================= When you activate or deactivate a Campaign, Mautic displays a confirmation message that shows the current reactivation behaviour setting. This helps you understand what happens to scheduled events before you confirm the action.