Before you start
- Ensure you have the permissions needed to create, edit, pause, resume, and delete a scheduled agent (by default, granted only to the Admin role). Anyone with Copilot access can see that an agent exists and when it runs.
- Access to the account that will own the agent. Every run uses the owner’s role scope and the owner’s own connector credentials, so a test under a different login proves nothing about what the agent will return.
- The instruction you intend to schedule (up to 4096 characters), or the
/skill-nameit will invoke. - A decision on entity scope and accounting basis, rather than whatever the composer happens to be set to.
- For an agent that calls a connector, confirmation that the owner has personally authorized it. See how to connect an MCP connector.
Test the instruction interactively
Everything a scheduled agent does unattended, it does under a fixed entity scope and accounting basis it cannot correct mid-run. These three steps reproduce that scope in the composer and prove the wording against it while you are still watching.Step 1: Reproduce the agent’s scope in the composer
In the Agents panel composer, set the entity selector to the single company the agent will be scoped to, and set the accounting basis to the value the agent definition will carry. Both default to All companies and GAAP, and both apply to the whole conversation rather than to one message. A scheduled agent takes these two values from its definition, and no one is present at run time to correct them, which is why matching them here is the test rather than a preliminary to it.Step 2: Run the instruction verbatim
Paste the instruction you plan to schedule into the composer and submit it. If the agent’s instructions will begin with/skill-name, invoke the skill the same way, with the same trailing arguments.
Sign in as the intended owner to do this if that is not you.
Read-only questions cannot change the ledger, so repeat this run as often as you need while you adjust the wording.
Step 3: Check the output against the records
Open the source records attached to the response and confirm the figures against them. For a scoped agent, confirm the numbers belong to one company. A consolidated total at this point means the entity selector is still on All companies, and the agent will repeat that on every run with nobody reading over its shoulder.Fit the instruction to what an unattended run may do
A scheduled run has a narrower tool set than the same instruction typed into the composer. These two steps bring the wording inside that boundary before you create the agent.Step 4: Reduce the instruction to reporting
Keep the instruction to a list, report, or summary that a person then acts on. Unattended runs are barred from creating a workflow, changing a workflow’s status, approving or rejecting a record, and applying a bulk reclassification, even when the owner holds those permissions. An instruction that asks for any of them works for you interactively and fails on the schedule. To have the agent support customer-facing work, keep delivery with a person: let the schedule produce the list and do the sending yourself. See how to send dunning emails with Copilot and Gmail for the split in practice.Step 5: Expect a connector to read, not to send
A connector is the one route an unattended run has to reach outside DualEntry, and it acts with the permissions of the credential that authenticated it rather than the owner’s DualEntry role. An unattended run gets the read-only half of that connector: any tool that writes or sends, whether that is emailing a customer, posting a message, or creating a record upstream, is dropped from the agent’s tool set before the run starts, whatever the connector’s settings say.- Do not schedule delivery. An instruction that asks the agent to email its result works interactively and produces a report instead on the schedule, because the send tool is simply not there.
- The connector’s Permissions section governs interactive runs, which is what its Interactive Tools heading means. Nothing set there widens what a schedule can do.
- Confirm the owner has personally authorized the connector. Installation is organization-wide but credentials are per user, and a connector showing no tools available is not connected for that person, so the run returns nothing rather than failing loudly.
Create the agent and prove one live run
With the wording settled, create the scheduled agent, let exactly one run land on a throwaway cadence, and confirm the output reaches whoever is meant to act on it.Step 6: Create the agent with both scoping fields set explicitly
Select Scheduled Agents in the Agents panel and create the agent with the wording you just tested. Set:- Name, unique in your organization, up to 128 characters, since this is what identifies runs in history.
- Entity scope. Left unset, the agent queries every company the owner can reach and returns consolidated figures on every run.
- Accounting basis, even where GAAP is what you want.
- Cadence. The schedule form requires an IANA timezone such as
America/New_Yorkand pre-fills the browser’s, so confirm it is the timezone the report belongs to rather than the one you happen to be sitting in. A schedule created through the API without a timezone resolves against UTC.
Step 7: Take one live run on a throwaway cadence
Set a cadence that fires within minutes: an interval of five minutes (the shortest allowed) or a weekly time a few minutes out. Let exactly one run land, then edit the cadence to the schedule you actually want. A calendar cadence set to a fixed minute can land up to four minutes late: DualEntry spreads those runs across a five-minute window so that agents set to the same round hour do not fire together. An interval cadence is not spread, and fires on time.Step 8: Confirm the output reaches a reader
Open the agent’s conversation. Every run appends one prompt and one response there, and that conversation is the only place output goes. There is no email digest, no Slack delivery, and no notification of any kind: nobody learns a run happened unless they open it. The conversation is also read-only. You cannot reply in it or ask a follow-up, so take any follow-up question to an ordinary composer session. The owner and organization admins can open it. Anyone else needs the session shared with the organization. Confirm that whoever is expected to act on the output can read it before you treat the schedule as done.If the agent invokes a skill
Test the skill under the same scope, not only the agent that calls it. The skill supplies the wording and constraints; the agent definition supplies cadence, entity scope, and accounting basis. Any constraint the output depends on belongs in the skill’s instructions rather than in the invoking message, because an unattended run has nobody to correct it. Editing a skill creates a new version and the audit trail records which version ran, so a result stays traceable to the wording that produced it. Ensure you have the permissions needed to edit a skill (by default, Admin only). Skill edits apply organization-wide, so a change you make to pass your test also changes what your colleagues get from the same slash command.Verify
The agent is ready when all of these hold:- The interactive run, under the same entity and basis as the definition, returned figures you traced to source records.
- The agent’s detail view still reads Active, with no Last Error.
- That run’s prompt and response are in the agent’s conversation.
- The run appears in the audit trail with the same detail as an interactive conversation, attributed to the owner and tagged as a scheduled run.
- Nothing in the instruction depends on sending, drafting, or writing through a connector, since an unattended run cannot call those tools.