Settings: Integrations and automations

Stack and provisioning

The tools a new client runs on, chosen by your agency's rules, and the build that sets them up in your order.

Read as Markdown

When you sign a client, two questions come before any build: which tools, and in what order to set them up. This page shows both answers for the workspace, and how far the build has got. Your agent plans the stack and the build, which needs the Pro plan.

Choosing the stack

Your agent runs plan_stack over the onboarding answers. Each line of the stack comes with the rule that chose it:

What the answers don't settle comes back as a question rather than a guess. You confirm each line or override it. An override needs a reason, and the page shows who made it and what it replaced.

Building it

Once the client's tools are connected, your agent runs plan_provision. It makes one plan in your build order: the client's signup mailbox, tool signups, the GoHighLevel sub-account and its fields and forms, Close, Calendly or iClosed, the application form, the domain and sending domain, phone numbers, WhatsApp, automations, Slack or Discord, Drive, payments, Meta, pages, and the end-to-end test.

Every line says how it is done:

• By PYLO's API where PYLO has a writer: Close's standard fields, statuses, pipeline and shared smart views, Calendly event types, Slack channels, and the SPF, DKIM and DMARC records through Cloudflare. PYLO adds what is missing and never deletes or renames anything. An SPF or DMARC record already on the domain is never replaced: the line shows both values for a person to merge.
• In your own browser, with a step pack or in explore mode, for tools with no API PYLO can use.
• By a person, as an inbox task with the exact values: paying for a tool, identity and A2P checks, buying a domain or a number, verifying a business.

Two things are refused by decision: creating a Notion workspace, and creating Meta campaigns or spend.

A few lines follow your SOPs' build closely:

• Three calendars, not one. The funnel calendar, the DM setting calendar and the dialing calendar, which books any day ahead with an hour's notice so dialers can book leads who did not book themselves. Each files its bookings on its own funnel, which is what the per-calendar filters used to do, and their links never contain one another.
• Notifications into the channels. After the Slack channels are made, PYLO's own notifications are routed to them: applications, booked and cancelled calls, end of day reports, call outcomes and failed payments.
• The dialing and closing hubs. A copy of your hub sheets for the client, with the calendar links, the brand sheets, the pre-call page and the rep app, where reps confirm calls and file the post-call form. Shared so anyone with the link can view.
• GoHighLevel for texts only. When GoHighLevel sends the texts and another CRM holds the pipeline, only the sub-account, its fields and tags, the phone numbers and A2P are built. No GoHighLevel pipeline or forms: PYLO's own confirming and post-call forms are used.

A line missing a value (a pixel id, a DKIM value from the email platform) waits for the answer, and the rest of the plan goes ahead. The DNS records are hard to reverse, and paying is people and money, so the plan is approved by a person, usually with a code sent to their phone.

What this page shows

The stack with each line's reason and any override, then the build grouped by step. Each line shows how it is done and where it stands:

• Done, proved by a read: PYLO read the tool back and found what the line set.
• Done, not yet proved: applied, but no read has confirmed it yet.
• Waiting for its run or its person: a browser line waiting for its run, or a person's task still open. Your agent runs each browser line in your own browser as soon as the plan is approved.
• Claimed by the person who did it: a person's own step (paying for a tool, an identity check) that its person closed from the inbox. No read can prove these, so they stay claimed with their reason, and they no longer hold the build open.
• Blocked, with the reason and what a person does instead.
• Waiting on an answer, Refused by decision, or Done by PYLO's own tool (automations are recipes, the end-to-end test is run_backend_test).

What the client gives

The stack is decided on the first day, so plan_access_checklist with no items can build the client's list from it: processor access, registrar access or the DNS records, Google Workspace accounts, the Business Manager partner invite, A2P details, a number never used on WhatsApp, each key through a key-drop link, and payment for every tool. Logins stay with the client. An item a read can reach (a tool connected, a key that works) is verified by that read. One no read can reach, such as the Google Workspace accounts or paying for the tools, is confirmed by you, from the chat with confirm_access_item or on the checklist, and recorded as yours.

The end-to-end test

run_backend_test runs the SOP's end-to-end test in a sandbox: an application, a booking, a cancellation, the confirming form, the post-call form and a booking on the DM calendar. A run that never reached the call path, because the calendar is not connected yet or no member can host the test booking, reads as incomplete and says why, never as passed. Nothing reaches the client's CRM, Slack, Discord or anyone's phone, and no meeting is booked in any calendar. Every check reads the record back. Afterwards only the records the test made are voided, found by the test's own address.

That sandbox run is the default. With mode live, the test lead goes through the real form and PYLO waits for a booking on the agency's own sandbox calendar, never the client's. A live run needs a code sent to your own phone or inbox, and the test lead is always the person who typed the code, with their own email. It files a real lead in the client's CRM, marked as a test, so it does not run while the workspace is in parallel mode.

Tracking on the funnel pages

Every page line on the build carries the exact capture snippet line to paste into the page's header, with the pixel id. PYLO's own hosted application form needs nothing added: the snippet carries the visitor's UTMs and a visitor id onto it, linked or embedded, and onto the booking link. A page line counts as done only when PYLO fetches the published page itself and finds the snippet and the pixel on it. Your agent gives it the page's address once the page is live.

This page shows the capture line under Tracking on the funnel pages, and the newest tracking check.

The tracking check

On Day 7 your agent runs run_tracking_check with your own email. It first hands you a tracked link: you open it in your own browser, apply as a qualified applicant and stop at the booking page, without booking. Then PYLO reads every hop and shows each here:

• The pages carry the snippet and the pixel, read by fetching them.
• Visits are arriving from the snippet.
• The application arrived with its four UTMs, not a form tool's empty placeholder.
• The visit is joined to the lead, which proves the visitor id rode from the page to the form.
• The first touch on the lead matches the application.
• The booking link you were sent carries the UTMs, so the booking keeps its source.

The lead is yours, never a client's lead, and no booking is made in the client's calendar. The go-live checks need the last tracking check to pass.