A long macro often starts as a short routine and slowly absorbs setup steps, the main task, recovery paths, and cleanup. It may still work, but changing one section becomes harder because every test has to cross the entire flow.
EmuloMobile provides the Run another automation action for a more modular approach. When that action runs, the current automation ends and the selected automation starts. The handoff is sequential: only one automation runs at a time.
This guide shows how to separate a reusable setup from the main routine, connect both macros, and test the boundary without creating a hidden loop.
Automate only routines allowed by the app or service involved. Chaining macros organizes your flow; it does not bypass a third party’s rules or confirmations.
When chaining macros is better than adding more steps
Keep a routine in one macro when its steps belong to the same small job and are normally changed together. Split it when a section has its own clear starting state, result, and maintenance cycle.
Common candidates include:
- a setup macro that reaches a known screen before several different routines;
- a recovery macro that returns the interface to a safe state;
- a login or navigation stage followed by a separate operational flow;
- two long stages that need to be tested independently;
- a shared preparation sequence that should have one maintained version.
Chaining is not the same as copying actions. A copied action becomes an independent duplicate. Run another automation transfers execution to a separate macro that remains editable on its own.
If all you need is a few related steps under one condition, a compound action is usually simpler. If the flow needs to remember a count or route within one execution, use variables and conditional actions instead.
Design the handoff before opening the builder
Write the chain as a short contract:
Prepare screen → confirm dashboard is ready → run Main routine
The source macro owns everything before the arrow. The destination macro must be able to start from the exact screen left by the source. That boundary needs an observable result, such as a stable title, image, or color—not just a fixed delay.
For the example in this guide, create two automations:
- Prepare dashboard starts from the target app and navigates to its dashboard.
- Process dashboard handles the repeatable work that begins on that dashboard.
Create and save the destination automation first. EmuloMobile can only offer another automation that already exists on the device as a target.
How to run another automation in EmuloMobile
Open the source macro in the builder. Its final useful step should leave the target app in the state expected by the destination.
1. Add the handoff action
Select Add Action, choose New Action, and then select Run another automation. The editor explains that the current automation will end and the chosen one will start, one at a time.
This is a handoff, not a temporary call. EmuloMobile does not return to the next step of the source macro after the destination finishes. Treat the action as the end of that source path.
2. Select the destination macro
Choose Process dashboard from the list of automations on the device. The current macro is not a useful destination: pointing chains back toward themselves creates a cycle rather than a reusable sequence.
If the editor says there is no other automation available, return to the automation list, create and save the destination, and then reopen the source macro.
Use the optional step note to make the boundary explicit, for example: Dashboard ready — hand off to processing. A descriptive note makes the chain easier to review later.
3. Protect the handoff with a condition
Add a condition to the Run another automation step that confirms the destination’s expected starting screen. Depending on the interface, that condition can look for a title with on-device OCR, match a reference image, or check a stable color.
For the dashboard example, use a condition such as Text on Screen: Dashboard and restrict its region to the header. The handoff then happens only after the source macro has actually reached that screen.
Avoid using only a long wait before the handoff. A delay expires whether or not the app finished loading; a screen condition describes the state the destination really needs.
4. Save explicitly
Confirm the action, return to the builder, and select Save. EmuloMobile keeps builder changes pending until you use that command. Leaving with unsaved changes can discard the new link between the macros.
What happens during the handoff
When the condition passes and Run another automation executes, EmuloMobile stops the source and prepares the selected destination in the same execution session. The destination then starts automatically. The screen-capture session and floating control remain part of that running session, so you do not start two macros in parallel.
The destination still has to match the device’s current resolution and orientation. EmuloMobile stores those properties with each macro and checks them during the handoff. If they do not match the current device mode, the destination is not started.
Build both macros in the same device mode when they belong to one chain. A portrait source handing off to a landscape destination requires the device to be in the mode recorded by the destination at the moment of the switch; do not assume the handoff rotates the app for you.
Practical example: separate preparation from repeated work
Suppose one routine needs to reach a dashboard before it can process a list. Keep the responsibilities separate.
In Prepare dashboard:
- start from the target app’s expected initial screen;
- dismiss an expected startup notice if it appears;
- navigate to the dashboard;
- verify the dashboard title;
- run Process dashboard.
In Process dashboard:
- verify the list container is visible;
- process one item;
- update a counter or another state variable;
- continue according to the macro’s own conditions;
- stop at an explicit completion state.
This arrangement lets you test the processing logic from a known dashboard without replaying startup navigation after every edit. It also lets another source macro hand off to Process dashboard, provided that source establishes the same starting state.
The destination should verify its own entry state too. The condition on the source protects the exit; the first condition in the destination protects the entry. That small overlap makes the boundary easier to diagnose if the target app changes.
Prevent accidental handoff loops
Draw the chain before you run it:
A → B → C → stop
Then inspect every Run another automation action. A chain such as A → B → A has no terminal macro and can switch repeatedly. EmuloMobile includes a rapid-switch safeguard that stops an excessive burst of handoffs, but the safeguard is a last resort, not a flow design tool.
Use these rules:
- give every chain a terminal outcome;
- do not link a destination back to its source unless a condition makes that return finite and testable;
- keep the handoff at the end of a clear path;
- use notes that name the expected screen and destination;
- review the whole chain whenever you rename, replace, or delete a macro.
If a cycle is genuinely required, control it with an explicit counter and exit condition. The variables guide explains how to limit attempts within a macro; for a multi-macro chain, the safest structure is still a finite sequence with a clear final stop.
Test each macro and then test the chain
Do not make the first test a full unattended run. Use a staged checklist:
- Place the target app on the destination’s expected starting screen and test the destination by itself.
- Test the source up to the step before the handoff.
- Confirm the handoff condition fails on the wrong screen.
- Put the app on the correct screen and confirm the selected destination starts.
- Check that the source does not continue after the handoff.
- Verify both macros were created for the current resolution and orientation.
- Follow every outgoing handoff and confirm the chain has a terminal result.
- Run the complete sequence while keeping the floating Play, Pause, and Stop controls visible.
If the destination does not start, first check that it still exists on the device, then compare its saved resolution and orientation with the current mode. If the switch happens on the wrong screen, tighten the condition on the source rather than adding a longer delay.
Make the boundary as clear as the actions
A useful macro chain is not merely a long flow cut into pieces. Each macro should own a coherent job, declare the screen it expects, and leave a state the next macro can verify. With those boundaries, Run another automation turns independent EmuloMobile macros into a sequential routine without hiding two simultaneous executions.
Explore EmuloMobile and build modular Android automations directly on the device.