You picked the best engine for each job, and that was the right call. The
cost turns up later, in the scheduling, dependency logic, and monitoring you
now maintain four times over.
A scheduler per service
ADF triggers, Databricks jobs, Function timers, and cloud schedulers each live in their own portal. Nothing shares a timeline, so nobody can say what ran when without checking each one.
No dependencies across platforms
Making a Databricks notebook wait on an ADF pipeline turns into a webhook, a queue, and a runbook no-one wants to maintain.
Tasks get rebuilt, not reused
The same steps, parameters, and schedules get recreated for every team, environment, and project. Because none of it is shared, a fix in one place rarely reaches the other five.
No single operational truth
Every platform keeps its own logs, run status, and audit trail. Answering "what ran, when, and why did it fail" means opening four dashboards and lining up timestamps by hand.
The jobs you already have become reusable building blocks. Nothing has to be
rewritten to get there.
1
Connect
Register your Azure, Google Cloud, and AWS platforms, then point Polysync at your secret vault: Azure Key Vault, AWS Secrets Manager, Google Cloud Secret Manager, or HashiCorp Vault. If you would rather not link one, Polysync can hold the credential in its own managed Key Vault.
2
Discover & import
Polysync reads each connected platform and imports its pipelines, notebooks, and functions, parameters included, as reusable job blueprints . Add your own inputs and outputs with default values for the tasks built on top.
3
Orchestrate & schedule
Build tasks from those blueprints, draw dependencies across platforms, and attach a schedule. Run it by hand first to prove it works. All of it is configuration, so there is nothing to compile, package, or redeploy.
4
Monitor, with an AI agent on watch
Every run, retry, and outcome lands in one execution history, alongside analytics dashboards and an inline dependency graph that shows where each execution sits. Turn on the AI monitoring agent and it watches those runs for you, explains each failure with the evidence behind it, and retries what is safe only within the limits you set.
Jobs, tasks, dependencies, and schedules are stored as
configuration, not code . That is what lets one workspace
carry thousands of executions a week without quietly becoming a codebase of
its own.
Cross-platform dependencies
Wire tasks together across every connected platform, whether they sit in the same cloud or three different ones, with On Success, On Failure, On Completion, and On Skipped triggers. Circular dependencies are detected and blocked before anything runs.
Visual schedule builder
Pick a frequency and Polysync writes the schedule for you, so there is no syntax to learn. Each one shows a plain-English summary, a preview of its next three runs, and the timezone it follows. Attach as many schedules to a task as you need and switch each on or off independently.
Concurrency & rate limits
Keep peak batch windows from tripping API throttles. Set concurrency caps and leaky-bucket or rolling-window rate limits, per platform or globally.
Live monitoring
Schedules, the dispatch queue, and every execution refresh on a live 30-second cycle. Filter by status or time range, follow a retry chain back to its first attempt, and open the dependency graph on any run to see exactly what it was waiting for.
AI monitoring agent
An agent that watches your runs on a schedule, explains why a run failed, shows the evidence behind it, and, only where you have granted it authority, retries what is safe. It starts with a built-in catalogue of common errors for every platform Polysync connects to and gets sharper from your instructions and feedback.
Auto-discovery & parameter mapping
Connect a platform once and Polysync imports its pipelines, notebooks, and functions with their parameters. Pipe output values from a parent task into a child task, even when the two run on different platforms, with no glue code.
Multiple instances, one organisation
Run a development instance beside production under the same organisation, and switch between them from the top bar. Each instance keeps its own platforms, tasks, schedules, and run history, so a change made in one never reaches the other, and every instance has its own bookmarkable address.
AI is there from the first question to the first failed run. It starts
with an assistant that answers questions, moves on to one that builds your
setup, and ends with an agent that watches your runs. At every step the
interesting part is not what it can do. It is
what it is not allowed to do without you .
Getting started and setting up
Ask Polysync, before you sign up
The assistant on this page answers questions about what Polysync does, which services it connects, and how the plans work, drawing on the same public documentation anyone can read. It only knows what is already public and never needs an account.
The Copilot answers in plain English
Inside the Setup Studio, questions are answered from your actual configuration rather than a generic manual: which tasks run on a platform, what a schedule does next, why a run was waiting, how last week's executions went.
It does the setup work too
Register a platform, import its jobs, build tasks from them, wire dependencies, attach a schedule, create a contention profile, or check a secret vault connection, all described in a sentence instead of clicked through a form.
Nothing changes until you approve it
Every change the Copilot wants to make is staged as a proposal, not executed . You see what it intends to do and approve or reject it. That includes starting a task run, which uses your own cloud resources. An unanswered proposal expires after ten minutes.
Your administrator can switch it all off
AI features are a per-organisation setting. One switch turns off the Copilot and the monitoring agent together, for everyone in your workspace, with no per-user cleanup and no partial state.
It only ever sees your workspace
Every question and every action is scoped to your own tenant and runs under your signed-in identity, so the AI cannot reach another customer's configuration or step outside what you are allowed to do yourself.
It treats its own findings as untrusted. Pipeline names,
descriptions, and imported values often come from systems Polysync does not
control, so the AI is instructed to read them as data and never as
instructions. Text smuggled into a pipeline name cannot talk it into an action.
Monitoring agent
Once your tasks are running, the AI monitoring agent watches them on a schedule,
works out why a run failed, and, only if you have given it the authority, retries
what is safe to retry.
It watches, then explains
On a schedule your plan sets, the agent finds failed runs, reads the run record and the platform's own error, compares it with earlier failures, and writes an insight in the Monitor: what it thinks went wrong and the evidence behind it. Acknowledge, snooze, resolve or dismiss it from there.
You choose how much authority it has
Authority comes in levels. Off does nothing. Observe diagnoses and writes insights but changes nothing. Recommend proposes an action, such as a retry, for a person to approve. Above that, on plans that include it, it can act within limits an administrator grants for a chosen scope, with an expiry. The AI can never raise its own authority.
Guardrails enforced by code, not by the model
The model only proposes. Deterministic code decides whether an action is allowed, and does any retrying itself. Rate caps, quiet hours, a storm breaker and a per-platform circuit breaker stop a run of failures turning into a run of retries. Every action is recorded in an audit trail with the authorization it relied on. Revoke a grant, switch the agent off, or flip the organisation switch and it stops.
Your instructions become rules
Tell it how your organisation works in plain words, for example never to retry a particular task. Rules apply to the whole organisation, a platform, a job, a task or one person. Colleagues can suggest rules for an administrator to approve, clashes are flagged, and a rule that says never always beats one that says allowed.
It arrives knowing common platform errors
A built-in catalogue of common failures covers every platform Polysync connects to, from Data Factory and Databricks to AWS and Google Cloud services, so familiar errors are recognised on day one instead of being learned from scratch.
It gets smarter, and you can train it
It keeps statistics on how earlier similar failures in your organisation turned out, stops reusing a diagnosis that people marked not helpful, and follows the rules you teach it. What it learns stays in your organisation: it is never shared with another customer and never used to train a model.
Ask it questions
Open the agent from the Monitor, or from any insight, and ask why a task failed, whether it has failed before, or what it is waiting on. It answers from the run history and configuration it reads, and it can propose a rule that you approve or reject before anything is saved.
You control what it can read
It reads run summaries, platform health and the platform's error text with known secret patterns removed. Error messages and configuration metadata can each be switched off. Parameter values, secret values and anything identifying a person are never sent to the model.
It can be wrong, so it shows its working. Every insight carries
the evidence it used, and takes a rating from you, which is how its accuracy is
measured rather than assumed.
Whatever the vendor, every connected service is registered, discovered, and
run the same way.
Azure Data Factory Azure Databricks Azure Functions Azure Logic Apps Azure Synapse Pipelines Microsoft Fabric Power BI Azure Kubernetes Service Azure Batch Azure AI Foundry Azure AI Foundry Project Azure OpenAI Azure Automation SQL Database
Google Cloud Composer Google Vertex AI Google Cloud Functions Google Dataflow
AWS Glue AWS Lambda AWS Step Functions Amazon SageMaker AWS Batch
Azure Key Vault AWS Secrets Manager Google Cloud Secret Manager HashiCorp Vault
Credentials stay in your vault. If you would rather not
link one, Polysync can hold them in its managed Azure Key Vault instead.
Either way they are encrypted at rest and read only at dispatch time,
never kept in application memory or written to logs.
One billing line for orchestration.
Your Azure Marketplace subscription covers Polysync itself; the pipelines it
orchestrates keep running on your own cloud account, billed as usual.
Polysync is general-purpose orchestration, but the same handful of patterns
come up again and again.
Enterprise data warehouse loads
Chain ADF ingestion, Databricks transformations, and Synapse or Fabric publishing into one nightly DAG, with retries and rate limits handled by the dispatcher.
ML and AI pipelines
Sequence feature engineering on Databricks, training on Vertex AI or Azure AI Foundry, and batch scoring on Azure OpenAI or Functions, with parameters passed between stages and no glue code in between.
Multi-cloud orchestration
Coordinate workloads spanning Azure, Google Cloud, and AWS from one DAG. A Cloud Composer job can trigger an ADF pipeline on success, with output parameters crossing the cloud boundary automatically.
Migration in flight
Orchestrate Step Functions, Glue, Lambda, SageMaker, and Batch alongside their Azure or Google Cloud counterparts in one DAG. Cut over service by service without rewriting orchestration.
Compliance and audit reporting
Every run, parameter, retry, and outcome is recorded in your tenant's own schema. When an auditor asks what ran, when, and with which inputs, the answer is a query rather than an excavation. The evidence SOX and APRA CPS 234 reviews ask for is already there.
Consolidating fragmented schedulers
Replace ADF triggers, Databricks job schedules, Function timers, and native cloud schedulers with a single scheduler that respects cross-platform dependencies and contention limits.
The Microsoft 365 Certification logo represents that this app has achieved
Microsoft 365 Certification. In addition to app security, this program reviews
the practices and procedures the app publisher employs. While customer data is
under control of the app publisher, you can rest assured that Microsoft has
validated that the app will handle it in a safe and secure manner.
What the certification adds. Microsoft 365 Certification is an
independent security and privacy audit of the application and the environment
that runs it. Beyond the safeguards below, it checked how we operate day to day:
patches applied within set deadlines, vulnerability scans every quarter,
multi-factor sign-in for all administrative access, security logs kept and
reviewed, and every code change documented and tested before it is released.
It includes an independent penetration test and is repeated every year, so your
security review can start from a finished audit rather than a blank questionnaire.
Polysync is a member of the NVIDIA Inception program.
Polysync is a managed service, so the platform underneath it is our problem
rather than yours. Here is exactly what that means, without the adjectives.
Hosted and stored in Australia, AI included
Polysync runs in Microsoft Azure's Australia East region (Sydney). Everything it stores, from your platform connections and schedules to the history of every run, is held in Australian data centres, and backup copies are kept in a second Australian region. The AI keeps to the same boundary: Ask Polysync, the Copilot and the monitoring agent all process their requests on a regional model deployment in Australia East.
Attacks blocked before they reach us
Every request to Polysync passes through Microsoft's enterprise web firewall before it reaches the application. Known attack patterns are blocked automatically, and Microsoft keeps those defences current rather than us.
No new passwords to manage
Your team signs in with the Microsoft work accounts they already have, so your existing multi-factor authentication and access rules apply unchanged. Polysync never sees or stores a password, and when someone leaves, disabling their Microsoft account removes their Polysync access at the same moment.
Your data is separated, not just filtered
Each customer's information sits in its own dedicated area of the database rather than being mixed into shared tables and filtered by a customer column. It is encrypted on the way to us and encrypted again at rest.
Credentials kept in a locked vault
Polysync's own credentials live in a dedicated Microsoft vault that cannot be reached from the public internet. Our services prove who they are to each other using Azure's built-in identity system, so there are no shared keys sitting around to be copied or leaked.
Automatic backups, managed by us
Your database is backed up automatically. We can recover it to any point in the last 35 days, and weekly, monthly and yearly copies are kept for longer-term recovery. Backup copies are held in a second Australian region, so they stay in the country too. If a restore is ever needed, we carry it out, so there is nothing for you to schedule or manage.
The AI has boundaries too, and you hold the controls.
One organisation-wide switch turns off the Copilot and the monitoring agent
together. The agent has its own switch, stays off until an administrator
enables it and records consent, and an administrator chooses how much
authority it has, what it may read, and when it may act. Parameter values,
secret values and anything identifying a person are never sent to the model,
your questions are never used to train anyone's AI model, conversations are
kept only for the length of your session, and an administrator can delete
the agent's stored findings at any time.
Every AI request, from Ask Polysync, the Copilot and the monitoring agent,
is processed on a regional model deployment in Australia East, so the AI
stays inside the same boundary as your data.
Orchestration sits in the middle of everything you run overnight, so it
matters who is behind it and what it is made of.
Australian registered company
Polysync is built and owned by Polysync Data Solutions Pty Ltd (ABN 87 683 785 686), an Australian registered IT consultancy. You are contracting with a local company under Australian law, bound by the Privacy Act 1988 and the Australian Privacy Principles, and the product is shaped by consulting work on real data platforms rather than by a roadmap written at a distance.
Built with Microsoft technology
Polysync runs entirely on Microsoft Azure and is built end to end with Microsoft's own development tools, database, and AI services. It was built for Azure from the start rather than moved there later. In practice that means your team signs in with the same Microsoft work account they use for Teams and Outlook, and your IT admins grant or remove access from the same Microsoft admin console they already use. There is no separate user list and no new password to issue.
On the agreement you already have
Polysync is a transactable Azure Marketplace subscription, so it arrives as a line on the Azure bill you already receive. There is no new vendor to onboard, and the pipelines Polysync orchestrates keep billing to your own cloud accounts exactly as they do today.
Nothing gets replaced. The engines you already pay for
keep doing the work. Polysync adds one schedule, one dependency graph,
and one set of access rules on top of them, so Data Factory, Databricks,
Fabric, and your native cloud schedulers carry on exactly as they are.
Not a quickstart and a support address. Every supported platform, job type
and secret vault has its own guide, covering what to fill in, which
permissions the connection needs, and what each parameter does.
No account, no trial, no sales call — the whole library is
open before you sign up.
One guide per connection
A guide for each of the 23 services and each of the 4 secret vaults, plus one for every job type behind them. They cover the authentication options, the exact permissions to grant, and the parameters that job accepts.
Searchable, not a PDF
Full-text search across the library returns the matching passage, not just a file name. Every topic has its own address, so you can send a colleague the exact page rather than the front door.
It follows you into the product
The guides are not a separate site you have to remember. Setup screens link straight to the relevant page, and the assistant reads from the same library, so an answer in chat matches the documentation exactly.
Evaluate before you commit. Read the guide for the
service you actually use and judge whether Polysync handles it properly
— before you spend a minute on setup.
Connect a platform, import jobs with their parameters, wire dependencies
across clouds, attach a schedule, and watch every run in one view.
Deliver workflows faster
Your existing platform jobs become reusable building blocks. Teams assemble a workflow from parameters and defaults instead of rebuilding the same logic for every new project.
Reduce operational firefighting
Schedules, manual runs, retries, and concurrency limits all live in one place. When something breaks overnight, whoever is on call has one place to look.
Avoid building another internal platform
Most teams end up building some version of this themselves, then own it for years. Polysync is that layer, already built, and someone else keeps it running.