Enterprise
Company-wide automation you can govern
Awish Enterprise gives every team templates, cross-app orchestration and Advanced Monitoring, with audit logs, SIEM streaming, custom retention, a workflow API and a private runtime — built around your processes and run where your review decides: Awish’s cloud, your own cloud account or your premises.
Tell us the process and the constraints. We build the first workflow with you, your review walks it end to end, and only then does it go to the next team.
Advanced Monitoring + governance · Audit logs and SIEM · Private runtime · Published DPA
Advanced Monitoring and governance, across every team
See every workflow’s health across the organisation, trace every change, and stream the record to the systems your security team already runs.
Advanced Monitoring verifies outcomes, catches silent failures and anomalies, and shows which workflows depend on a broken connection, filterable by team. Governance keeps the record your review asks for.
What governance includes
Audit logs
Who did what, in which workflow, and when — readable by your review.
Workflow change audit
Every change with the version before and after, so new behaviour traces back to the edit that caused it.
SIEM integration and log streaming
Workflow and monitoring events streamed into the SIEM your security team already watches.
Custom retention
Monitoring history kept for 365 days or the period your policy requires.
Workflow API and custom integrations
Trigger and manage workflows from your own systems, and reach internal tools through integrations built with our team.
Private runtime and Enterprise SLA
Workflows run in a private runtime, with an Enterprise SLA and a dedicated account manager.
What Awish Enterprise builds for you
Not a workspace with more seats. A team that writes your workflows, on your applications, and runs them where you decide.
Workflows developed for your request
You describe the process as it actually runs — the loops, the exceptions, the thresholds, who signs off. We scope it with your team and write the workflows around it. The result is plain-language descriptions you own, so your own people can read, change and extend them without us.
Describe your process to usOn the applications you already use
No migration and no new system of record. The workflows are written against the CRM, inbox, ticketing, finance and chat tools your teams already run — across 1500+ integrations today — and each connection is granted one app at a time, by your account holder, before anything runs.
Check your applicationsRun where you decide
In Awish’s cloud, where every customer already runs in a dedicated container with its own credentials and network identity. In an environment inside your own cloud account. Or on your own premises, on infrastructure you operate. The controls are the same in all three; your review chooses.
See the three options
Where it runs
The same workflow, with the same controls, in whichever of the three your review chooses.
- Awish cloud. A dedicated container per customer, with its own credentials and network identity. Nothing to provision; the first workflow can run the week it is scoped.
- Your cloud environment. An environment set up inside your own cloud account, so the workflows and their run records live where your other systems already do. Regions and services are scoped with your review.
- Your own premises. On infrastructure you operate, for organisations whose review requires it. We scope the requirements together and put in writing what we commit to.
Moving the workflow closer to home does not loosen anything. The plan a reviewer reads before any connection, the per-app grants, the gate where a named person decides and the record of every run are the same in all three — because they are the workflow, not the hosting.
What is in place today
Every item here is something we can evidence. Nothing on this page is aspirational.
Per-app permission model
Connections are granted one app at a time, by the account holder, before a workflow runs — and can be declined or revoked on their own.
Approval gates on sensitive actions
External messages, refunds and publishing hold for a person by default, and the decision is recorded with the run.
Isolated execution per customer
A dedicated container per customer with its own credentials and network identity — not a shared runtime.
Published DPA
GDPR, UK GDPR and DPA 2018, CCPA/CPRA, EU SCCs and the UK Addendum. Public, not gated behind a sales call.
Transport and credential hygiene
HTTPS throughout with a content-security policy and an allow-listed CORS; passwords hashed with bcrypt, short-lived access tokens with separate refresh tokens.
Payments out of scope
Card data never reaches Awish servers; payments are processed by Stripe, a PCI DSS Level 1 Service Provider.
Audited connection layer
App connections are established through Composio, which holds a SOC 2 Type II report — that report is Composio’s, and we say so rather than borrow it.
Coordinated vulnerability disclosure
A published disclosure path at support@awish.ai, so a finding from your own team has somewhere to go.
How an engagement goes
Nothing goes to a second team before the first workflow has run for real, where you chose to run it, and your review has walked it. The pace is set with you; the order is not.
It starts with your process in your words: which loops, which systems, where a person has to decide, and where it has to run. We build the first workflow from that, on your own applications, in the environment you chose, with its approval points live — so the first thing your team sees is the real thing running.
Your security and procurement people then walk that workflow end to end and get their questionnaire answered from what is configured. Only after that does the next workflow, or the next team, follow — with the same grants, the same gates and the same record.
What each person at the table gets
The same engagement, read four ways — so nobody has to search the page for their paragraph.
Security
A permission map per workflow before anything connects; grants scoped to one app each and revocable on their own; execution in a dedicated container, in your cloud or on your premises; and a run record that says who approved what.
IT and operations
Workflows on the systems you already run, with nothing migrated. In your own environment if your review requires it. Connections granted by the account holder and withdrawn the same way — and a withdrawn connection stops every workflow that used it.
Procurement and legal
A DPA you can read before the first call, written against GDPR, UK GDPR, CCPA/CPRA with SCCs and the UK Addendum. Card data handled by the payment provider, never by us. A scope document that says what we commit to — and what we do not.
The team that will use it
Their process, written for them, in plain language rather than a builder to learn. Approvals in Slack, WhatsApp or Telegram, where they already are. Workflows they can read, change and extend themselves after the engagement ends.
What a review can walk through
Take the first workflow and follow it end to end. Every step is something a reviewer can see for themselves, not something we assert.
Read the plan before anything connects
A described workflow becomes a plan first: the trigger, every step, every application it will touch and the point where it stops for a person. Nothing is granted or run while that plan is still being read.
Grant scope one app at a time
Each connection is requested on its own and approved by the account holder. A workflow given your CRM cannot read your drive, and any grant can be declined or revoked later without touching the others.
Put a named person on the sensitive steps
External messages, refunds and publishing hold for approval by default, in the channel your team already watches. Who approved what is recorded with the run, not reconstructed afterwards.
Read the record where it ran
Every run keeps what was proposed, what was approved and what was carried out — in the environment you chose, whether that is a dedicated container in Awish’s cloud, your own cloud account or your own premises.
Who you are working with
A named contact, not a queue
An engagement has a person on our side who scoped it, knows your workflows by name and answers your security and procurement questions directly. The questionnaire goes to them, and comes back from them.
Built with you, then yours
The workflows we write together are plain-language descriptions your team can read, running in the environment you chose. When the engagement ends you are not left with a black box: change the sentence and the plan changes with it.
Procurement questions
Do you build the workflows for us, or do we pick templates?
We build them. In an engagement we scope and write the workflows around your process — the systems it crosses, the thresholds and the people who sign off. Templates are only a starting point; the result is yours, in plain language your own team can read and change afterwards.
Can it run in our own cloud account?
Yes. We set up an environment inside your own cloud account and run your workflows there, with the same per-app grants, approval gates and run record as in Awish’s cloud. Which regions and which services it touches are scoped with your review.
Can it run on our own premises?
Yes. For organisations whose review requires it, the workflows run on infrastructure you operate. We scope the requirements together and put in writing what we commit to — and what we do not.
Does it work with the applications we already use?
That is the point. Workflows are written against the applications your teams already run — across 1500+ integrations today — and each connection is granted one app at a time, by your account holder, before anything runs.
Can we run a security review before committing?
Yes, and we would prefer it. Pilot one workflow, then walk it end to end: the plan before any connection, the per-app grants, the approval gate, the run record. Send us your questionnaire and we answer it from what is configured, not from a deck.
Is a Data Processing Agreement available?
Yes. Our DPA is published, not gated — it is written against GDPR, the UK GDPR and Data Protection Act 2018, and the CCPA/CPRA, and it covers international transfers through the EU Standard Contractual Clauses and the UK Addendum.
What happens to our connections if we stop?
Every app connection was granted one at a time by your account holder and can be revoked the same way, at any time, without touching the others. Nothing keeps running against an account you have withdrawn.
Bring us the process and the constraints
Tell us which loops your teams repeat, which applications they run on, where it has to run and who needs to sign off. We scope the first workflow with you and answer your questionnaire from what is configured.
Your cloud or your premises · Published DPA · No certification we do not hold