Customer-managed access
Employees do not create public accounts. Access begins with customer administrator invitations and the roles configured for the tenant.
Security begins with a documented operating model, not a collection of badges.
AlchemyWorkflow is delivered through managed enterprise access and a scoped implementation. The security design connects user roles, integration permissions, workflow controls, human approvals and execution records.
Important:
This page describes the intended control model and areas reviewed during implementation. It does not claim certifications, hosting locations, encryption specifications, recovery objectives or identity features that have not been confirmed for the production service.
Control principles
What is designed into each implementation.
Scoped implementation
Data sources, allowed actions, approval boundaries and operational owners are defined during discovery and recorded in the implementation scope.
Minimum necessary data
Workflows should access and move only the records and fields required for the agreed process.
Human control for higher-impact actions
Customer-facing, financial, legal or otherwise sensitive actions can remain subject to review and approval.
Traceable execution
Workflow runs can preserve triggering context, decisions, connected actions, owner assignments, exceptions and completion status.
Shared responsibility
AlchemyWorkflow configures and operates the service within the agreed scope; customers remain responsible for their users, source data, connected-system authority and business decisions.
Implementation lifecycle
Security decisions are made before a workflow goes live.
1. Discovery
Identify the systems involved, data categories, process owners, risk points and required approvals.
2. Access design
Define administrators, workflow owners, operators, reviewers and users who only need visibility.
3. Integration review
Confirm authentication method, permission scope, fields used, actions permitted and failure behavior.
4. Workflow testing
Validate normal paths, duplicates, missing data, permission errors, unavailable systems and manual escalation.
5. Production release
Publish the approved configuration and provide customer administrators with the agreed operating controls.
6. Ongoing review
Review access changes, workflow revisions, exceptions and integration behavior as the operating model evolves.
Controls need a named owner.
AreaExpected controlPrimary ownership
Identity and access
Administrator invitation; role allocation; removal of access when users leave or change responsibility.
Customer administrator with implementation support.
Workflow changes
Named ownership; controlled editing and publishing; testing before production release.
Authorized workflow owner and customer administrator.
Connected systems
Tenant-specific authorization; minimum required permissions; documented read and write actions.
Customer system owner and implementation team.
Approvals
Named reviewer or group; decision status; escalation when approval is delayed or rejected.
Customer-designated business owner.
Execution records
Trigger context; path selected; action status; exception and assigned owner.
Operational owners according to role.
Data lifecycle
Retention, export and deletion requirements documented in the applicable agreement and tenant design.
Customer and AlchemyWorkflow under the contract.
Data boundary
Define what the workflow needs—and what it should never receive.
During discovery, teams should document:
- Data fields required for decisions and actions
- Systems that remain the authoritative source of record
- Categories of sensitive data excluded from the workflow
- Approved recipients and downstream systems
- Retention, export and deletion requirements
- AI services, if any, permitted to process workflow context
Customers should not submit regulated or sensitive categories unless the applicable agreement, architecture and controls expressly support that data.
Claims we will not leave ambiguous.
Is AlchemyWorkflow SOC 2 or ISO 27001 certified?
This website does not claim either certification. Current assurance materials and any customer-specific security requirements should be discussed during the sales and security review process.
Does the platform support SSO or MFA?
Authentication requirements should be confirmed during discovery. They are not represented here as generally available features until the deployment and identity design are agreed.
Is each tenant a physically separate deployment?
The exact isolation model must be documented in the order, SOW or security documentation for the customer. The term dedicated tenant does not, by itself, promise a separate cloud account, database or infrastructure stack.
Where is customer data hosted?
Hosting region, infrastructure provider and any data residency requirement must be confirmed for the actual production deployment and reflected in the agreement and DPA.
Is customer data used to train AI models?
No blanket claim is made on this page. Any AI provider, input handling, retention and model-improvement terms must be documented for the services actually enabled in the customer tenant.
How are security incidents handled?
Incident contacts, notification commitments and responsibilities should be stated in the signed agreement and the operational procedures applicable to the production service.
Bring your security and data requirements into discovery.
We will identify the controls that must be confirmed before the implementation scope is finalized.
Contact Sales