When a customer needs more than 40 scheduled workflows, the support team can raise their limit by updating one value, with no code change, no deploy, and no downtime
Contents
1. Before You Start
2. How the Limit Works
3. What the Customer Sees at the Limit
4. Checking an Instance's Current Limit
5. Raising the Limit for an Instance
6. Verifying the Change
7. Lowering or Resetting the Limit
8. Frequently Asked Questions
1. Before You Start
You will need:
A confirmed request from the customer (or their account owner) to raise their scheduled workflow limit, and the number they need.
Database access to the specific customer instance whose limit is being changed. The agreed new limit value (a whole number greater than zero).
Access requirements: This change is performed by the Dazos support / operations team only. There is no screen in the CRM for customers or admins to change their own limit — it is set directly in the instance database by Dazos.
If a customer reports they cannot create more scheduled workflows, no application update is required to help them. The limit is adjustable per instance using the steps in this guide.
2. How the Limit Works
The limit is stored as a single key/value setting inside each customer instance, under the name max_scheduled_workflows .
Behavior | Result |
Setting is present with a value (e.g. 40 , 100 ) | The CRM uses that number as the maximum |
Setting is absent, blank, or not a positive number | The CRM falls back to the standard limit of 40 |
Because every customer instance keeps its own copy of this setting, the limit is per instance by nature. Changing one customer's limit never affects any other customer.
Important: The default is 40 for every instance and stays that way until support explicitly raises it. Until then, every instance behaves exactly as it always has.
3. What the Customer Sees at the Limit
The limit is enforced on the workflow creation screen (Settings → Automation → Workflows → Add Workflow).
While the customer is below their limit, they can create Time Interval (scheduled) workflows normally.
Once they reach the limit, the "Time Interval" trigger option is disabled and the screen shows: "Maximum number(40) of scheduled workflows has been exceeded" (the number shown reflects whatever the instance's current limit is).
Raising the limit re-enables the Time Interval option and updates the number shown in that message — immediately, with no code change.
4. Checking an Instance's Current Limit
Before changing anything, confirm what the instance is set to. Run this read-only query against that customer's instance database:
SELECT param_val
FROM vtiger_settings
WHERE param_name = 'max_scheduled_workflows';
Result | Meaning |
A number (e.g. 40 , 100 ) | That is the instance's current limit |
No rows returned | The instance has no override and is using the standard limit of 40 |
Tip: If the query returns no rows, you do not need to insert one before raising the limit — the next step handles both cases. The standard deployment seeds this row at 40 , but a missing row still resolves to 40 safely.
5. Raising the Limit for an Instance
Run this update against the target customer's instance database only. Replace 100 with the agreed new limit.
UPDATE vtiger_settings
SET param_val = '100', modified = NOW()
WHERE param_name = 'max_scheduled_workflows';
1. Double-check you are connected to the correct customer instance before running the statement.
2. Run the UPDATE .
3. Confirm one row was affected.
If the check in Step 4 returned no rows, insert the setting instead, then it will be in place for future changes:
INSERT IGNORE INTO vtiger_settings (param_name, param_val, created, modified) VALUES ('max_scheduled_workflows', '100', NOW(), NOW());
Important: Always confirm the target instance first. This setting lives inside each customer's own database, so a value entered against the wrong instance changes the wrong customer's limit. There is no cross-instance lookup — you are always editing exactly the instance you are connected to.
6. Verifying the Change
1. Re-run the read query from Step 4 and confirm param_val shows the new number.
2. Ask the customer (or check on their behalf) to open Settings → Automation →
Workflows → Add Workflow.
3. Confirm the Time Interval trigger option is available again and that the on-screen maximum reflects the new number.
The change takes effect on the next page load — there is nothing to restart or redeploy.
7. Lowering or Resetting the Limit
To return an instance to the standard ceiling, set the value back to 40 using the same UPDATE from Step 5 with 40 in place of the new number.
Tip: Lowering the limit below the number of scheduled workflows a customer has already created does not delete or disable those existing workflows. It only prevents them from creating new ones until they are back under the limit. Existing scheduled workflows continue to run normally.
8. Frequently Asked Questions
Q: Does raising the limit affect any other customers? No. The setting lives inside the customer's own instance database, so the change is isolated to that one instance.
Q: Will existing workflows stop working if I change the limit? No. The limit only controls how many scheduled workflows can be created on the workflow screen. It has no effect on how existing workflows run on their schedule.
Q: Do we need a deploy, release, or downtime to change a customer's limit? No. It is a single database value. The change is live on the customer's next page load.
Q: A customer is brand new and the query returns no rows — is that a problem? No. A missing setting resolves to the standard limit of 40 automatically. You can insert the row at the value they need (see Step 5).
Q: Is there a maximum value we can set? The setting accepts any whole number greater than zero. Use judgment for very large values — a high number of scheduled workflows increases the customer's automation load. There is no hard cap enforced by this setting.
Q: Can the customer change this limit themselves? No. There is no customer-facing screen for it. It is adjusted by the Dazos support / operations team only.
Q: What number should I use when raising it? Use the value the customer requested and that account management approved. There is no default "raised" number — only the standard fallback of 40 .
Need Help?
If you run into issues:
1. Re-run the read query in Section 4 to confirm the current stored value for the instance.
2. Confirm you were connected to the correct customer instance when you made the change. \
3. Confirm the customer is checking the Add Workflow screen and has refreshed the page.
4. Escalate to engineering with the instance name and the stored value, referencing CRM-2878.