Named resources
Let a workflow refer to an approved connection rather than repeating endpoints and credentials in every process.
Connections
Connect the systems the work already depends on
A useful workflow rarely lives on its own. Pūnaha gives you named connections for business systems, databases, email and AI, so the workflow can refer to an approved resource instead of carrying credentials and provider details through every step.
Approved connection
Visible workflow step
Useful result
Connection options
Choose the right route for each system
| Connection | Current capability | What to validate in your environment |
|---|---|---|
| HTTP services | Named HTTP connections for workflow calls, with deterministic product coverage | Allowed destinations, TLS, authentication, request limits and response handling |
| SMTP connections and workflow email actions, with deterministic and online test coverage | Sender policy, delivery, security controls and operational ownership | |
| Microsoft 365 | Configurable Microsoft 365 connection settings | Tenant consent, Microsoft Graph permissions and live behaviour in the chosen tenant |
| Databases | Connection settings for SQL Server, PostgreSQL and MySQL | Network path, TLS, database permissions, query safety and live target behaviour |
| Local AI | Local GGUF model execution through llama.cpp | Model provenance, licensing, hardware fit and content policy |
| External AI | Supported provider configurations referenced by model deployment resources | Provider credentials, terms, data movement, model suitability and live service behaviour |
| Messages and webhooks | Workflow modules for durable messages and external event-driven calls | Delivery guarantees, retries, authentication and the receiving system's behaviour |
Connection controls
Keep provider details at a clear boundary
Encrypted secrets
Store configured connection secrets encrypted at rest and do not return them through the settings API.
Resource access
Control who or which service can use a connection, separately from the workflow that refers to it.
Explore access governanceTarget-specific validation
Test the actual provider, account, network and permissions before treating a configured connection as production-ready.
Visible workflow use
Place a connection call in the workflow so people can see where information leaves the process and what happens next.
Failure paths
Plan what the workflow should do when a target is slow, unavailable or returns an unsuitable result.
A practical connection path
Treat a successful setup screen as the beginning of the test
The connection has to work inside the intended workflow and operating environment.
- 1
Define
Choose the target, purpose, owner and data that may cross the boundary.
- 2
Configure
Create the named connection and store the required secret or provider settings.
- 3
Authorise
Give the appropriate person or service access to use it.
- 4
Exercise
Run representative success, denial, timeout and failure paths against the intended target.
- 5
Operate
Monitor use, renew credentials and revisit the boundary when the provider or workflow changes.
Provider choice
Keep the workflow focused on the job
Provider details change more often than the business purpose of a process.
Pūnaha keeps model deployments and enterprise connections as resources that workflows can refer to. That separation makes the process easier to understand and gives administrators a clearer place to change a provider, endpoint or credential.
Configuration support is not the same as universal certification. Live provider checks still need the customer's account, consent, network path and acceptance criteria.
Workflow intent
Describe what the step needs to accomplish.
Connection resource
Hold the approved provider and protected settings at a named boundary.
Environment evidence
Confirm the real target behaves as required before operational use.
Connection questions
Does configuring a provider prove it will work in our environment?
No. Configuration and deterministic product coverage should be followed by live validation with the intended account, consent, permissions, network and target service.
Can a workflow use more than one AI provider?
Yes. Different steps can refer to different configured model deployments when that makes sense for the work.
Are connection secrets exposed through the settings API?
No. Configured secrets are encrypted at rest and are not returned through the settings API.
Can connection access be restricted?
Yes. A connection is a governed resource, so access can be assigned to the appropriate people, groups or services.
Bring the systems your workflow needs to reach
We can map the connections, data paths, permissions, failure behaviour and live checks needed for a useful evaluation.