We noticed that if we create a job using the API with a queue_uuid, while the job will be put in the queue correctly, they also appear in the “Unscheduled Jobs” list, which is supposed to show jobs that are not in any queue only.
Also, unlike normal jobs, this “API-created“ job will not automatically disappear from the queue when you schedule it.
This behaviour is very consistant - you can easily replicate it yourself. Please check it and let me know when this can be fixed.
I actually contacted ServiceM8 Support last month and provided an actual example from a client, which is not suitable to share here as it contains the client’s information. Please check the support ticket #311736 if possible.
Thanks so much mate - I thought that field is not required as it should be determined by the queue assigned to. So, do you need to calculate the date based on the timeframe of the queue? Or it actually accepts any date?
It accepts any date. Just doble check correctness of the date format that you put in. Sometimes, if it is in wrong format, it does not process it properly.
Based on how queues and the Unscheduled jobs list are meant to work, a job that’s sitting in a queue shouldn’t be lingering in Unscheduled unless it’s expired from the queue, and a job that gets scheduled should be removed from the queue.
In the Dispatch Board, the “Unscheduled jobs” list is for jobs that “require action”, and one of the ways to action a job is to place it in a queue. If a job is still in a queue on its expiry date, it’ll automatically appear in the Action Required and Unscheduled jobs lists for review. Separately, jobs are automatically removed from queues when they’re scheduled.
If you’re creating jobs via the API, it’s worth double-checking you’re setting a future queue_expiry_date along with the queue_uuid, since all jobs in queues have expiry dates and the API supports both fields.
As a short-term workaround, you can manually remove an affected job from a queue in the Online Dashboard by right-clicking it and choosing “Remove from queue” (this immediately removes the job from the queue).
Can you reply to support ticket #311736 with a redacted sample of the API payload you’re using (including queue_uuid and queue_expiry_date) and the UUID of one test job so we can get this investigated?
In ServiceM8, jobs in queues are expected to have an expiry date, and if a job is still in a queue when it reaches its expiry date, it’s flagged for review and automatically appears in the Action Required and Unscheduled jobs lists.
That lines up with what vitaliy_kulish mentioned: when creating/updating a job via the API, it’s worth setting both queue_uuid and queue_expiry_date.
Also, when queues are working normally, jobs are automatically removed from queues if they are scheduled, or if their job status changes to Completed or Unsuccessful.
If you’re seeing the job stay in the queue after scheduling even when queue_expiry_date is set appropriately, reply to ticket #311736 (via support@servicem8.com) with a minimal, de-identified example payload and the resulting job record fields (queue_uuid, queue_expiry_date) so we can reproduce it.
When creating or updating a Job via the API, the Job record supports both queue_uuid (“The UUID of the queue this job belongs to.”) and queue_expiry_date (“The date and time when the job expires from the queue.”).
In the product, all jobs in queues have expiry dates, and while each queue can have a default expiration window, expiry dates can always be customized by jobs.
So to answer your question: queue_expiry_date can be set to whatever date/time you want (it’s a per-job expiry), and if you want it to match the queue’s default window you can read the queue’s default_timeframe (days) and calculate queue_expiry_date from that (the API example value looks like 2026-03-01 12:00:00).
Also note that if a job is still in a queue on the expiry date, it automatically appears in the Action Required and Unscheduled jobs lists, so an expiry date that’s already passed will show up in Unscheduled even though it’s in a queue.
Separately, jobs are meant to leave queues once scheduled: jobs are automatically removed from queues if they are scheduled.
If you’re still seeing jobs stay in the queue after scheduling (with a sensible queue_expiry_date set), contact our Support team from your account via Help → Contact Support Team and reference ticket #311736 so we can dig into the API-specific behaviour.