Someone asked me a specific question last month. He had five phones and wanted them to run the same workflow at the same time. Would the commands cross over, he asked, so that one phone ended up tapping on another one behalf.
The concern is legitimate. People who ran device farms a few years ago mostly hit that problem: several devices sharing one session, so telling the first one to tap a button made the others tap too. It deserves a straight answer.
Will they conflict
No crossing over.
Starting with version 1.2.0, each device has its own independent session. That change exists specifically to remove the conflict caused by multiple devices sharing a session. The behaviour now is that five devices running one workflow each execute their own, and commands only go to their own device.
The change is recorded in the version history, described as adding a separate session per device to avoid conflicts when several devices use the same session simultaneously.
So at the tool level, concurrency across devices is safe. What deserves attention is everything below.
What actually interferes is resources
Tasks do not interfere, but devices do compete for resources. Three kinds.
Bandwidth shows up first. If a batch pushes files, several devices uploading at once slow each other down. Everything gets slower and the total time is not necessarily shorter than running in batches.
Machine resources and USB power come second. Invisible with a few devices, obvious past a dozen. USB especially: many ports and long cables lead to insufficient power and unpredictable dropouts. These are the hardest faults to trace, because they look like a random device going offline with no pattern. A powered hub solves most of it.
The third is at the account level. One account operated by several devices in a short window is itself a risk signal. That has nothing to do with the tool and everything to do with how it is used. My suggestion is one account per device. When you need more accounts, add devices rather than rotating several devices through one login.
One workflow everywhere, or separate workflows
Both are reasonable. It depends on the nature of the task.
If every device does the same thing, such as each posting one item or each running the same check, one workflow dispatched by group is the least effort. Configure once, cover a batch.
If each device does something different, such as different accounts posting different content or different shops running different flows, configure separate workflows and dispatch them separately. Do not force the differences into one template. The parameters multiply until you can no longer remember which value belongs to which device.
An easily missed detail: wait times
Under concurrency, networks and performance differ between devices. A step waiting five seconds may be exactly right on one and too short on another.
The symptom is that most runs pass and one or two fail occasionally, with the failing device changing each time. When that pattern appears, check the fixed waits first.
The more robust approach is to replace wait N seconds with screen-based detection, using image templates to express wait until this button appears. Each device then proceeds at its own pace, and speed differences stop causing failures. The documentation covers how to configure them.
How to arrange it
My advice is to work up from small rather than starting at the target.
Run the same workflow on two devices, then check the actual result on each phone to confirm commands did not cross over. It looks redundant, but it gives you a baseline you can trust.
Once that holds, dispatch by group. Light tasks can go to everything at once. Heavy tasks go in batches of five to ten.
After the run, check Execution History. Then increase the device count step by step, watching two indicators: whether dropouts increase, and whether total time is still falling. If total time stops improving at some level, or dropouts climb sharply, that is the ceiling for your setup. There is no benefit in going higher.
One last word on accounts
I raised this earlier and want to close on it, because it is the most common way multi-device setups get into trouble.
Concurrency at the tool level is safe. Devices do not interfere with each other. But if you rotate ten devices through a single account, the platform sees one account active in ten places at once. Whether automation is involved makes little difference. The same pattern by hand carries the same risk.
So before configuring concurrency, settle the account-to-device mapping: one account per device, and more devices when you need more accounts. With that premise in place, how you arrange the runs is a detail.
With one or two devices, concurrency can wait. Once you pass five and manual tapping starts to feel slow, work through the order above.
Frequently asked questions
- Do tasks interfere when several phones run the same workflow?
- No crossing over. Since version 1.2.0 every device has its own independent session, which removed the conflict that used to occur when multiple devices shared one session. Five devices running the same workflow each execute their own, and commands do not land on the wrong device.
- So what does interfere?
- Three kinds of resource. Bandwidth, since simultaneous large uploads compete. Machine resources and USB power, since insufficient delivery with many ports causes dropouts. And accounts, since the same account being operated on several devices at once is a risk signal regardless of the tool used.
- One workflow across many devices, or separate workflows?
- It depends whether the tasks are identical. If the same action repeats on every device, such as each posting one item, one workflow dispatched by group is simplest. If each device does something different, configure separate workflows rather than forcing the differences into one template.
- Do inconsistent wait times between devices cause confusion?
- Not confusion, but they do desynchronise. Networks and performance differ, so the same wait duration has different effects on different devices. If a step must wait for a specific screen, use image-based detection rather than a fixed number of seconds.
- If one device fails, does it affect the others?
- No. Each device is an independent execution, so one failure does not interrupt the rest. The failed device gets its own record in Execution History with the error message, and you work from that.
- Is there a recommended concurrency level?
- There is no universal number. It depends on task weight and your hardware. Light tasks tolerate more. Heavy tasks work better in batches of five to ten. Start with five and watch total time and device stability, then increase until dropouts rise or total time stops improving. That is your ceiling.
- Is there a risk in running the same account across several devices?
- Yes, and this is the part that genuinely deserves attention. One account operating across several devices in a short window is a behaviour pattern platforms flag. Keep one account per device, and add devices when you need more accounts, rather than rotating several devices through the same login.
- How do I confirm there is no interference?
- Two ways. Set concurrency to two devices, run once, and check the actual result on each phone. Then go through Execution History line by line and look for any device reporting an error that belongs to another. Only scale up after that baseline holds.
Try two first
Get two devices stable, then add more
Software is completely free and runs on your own computer.