Start and register a request
Start a workflow, identify or suggest the appropriate process, collect information, complete a form, and create a request, case, or record.
AI-to-Workflow Integration
For Process Owners and IT teams that need user requests to move from conversation into controlled workflow actions and status tracking.
Review the workflow, required permissions, data, and Integration scope before implementation.
BasisAssistant can connect to Engine Workflow so a user conversation can move into a defined business process instead of ending with an answer. The assistant collects required information, starts the appropriate workflow based on configured rules, runs permitted actions, and retrieves workflow status or results.
This Integration is available across Enterprise plans. Practical operation depends on the workflow design, roles, permissions, business rules, and data defined for that process.
The internal connection between BasisAssistant and Engine Workflow is available in Enterprise environments.
When a user request needs to become a business action, this Integration connects the conversation to an already defined workflow. BasisAssistant sends approved information and actions to Engine Workflow and receives status or results in return.
The connection is two-way. The assistant can participate without bypassing the workflow rules and permissions set by the organization.
Each customer scenario is configured for its workflow, required data, request interpretation, and access permissions. This does not necessarily require custom software development.
Each step follows the workflow, required information, and permissions defined for that process.
The process starts with a user request. BasisAssistant collects the information required by the workflow and proceeds only when mandatory fields are complete.
A workflow can start from a direct user request, detected intent, a user selection, or a predefined rule.
BasisAssistant asks for the information required by that workflow. Required fields must be complete before execution.
Once the required input is ready, the permitted workflow or action can start in Engine Workflow.
The workflow can assign the request to a person, role, business unit, work queue, or defined task.
BasisAssistant retrieves the permitted status, result, or next action within the user's access level.
Workflow design and permissions determine which actions are available in each scenario.
BasisAssistant does more than collect information. It can run actions already defined and permitted in Engine Workflow, including registration, assignment, approval, human handoff, and follow-up.
Start a workflow, identify or suggest the appropriate process, collect information, complete a form, and create a request, case, or record.
Register structured data, notes or a conversation summary, and transfer files, images, or documents when the workflow includes the required fields.
Route a request to a person, role, business unit, work queue, or responsible team and create a task when defined.
Change an allowed workflow stage or status, review current progress, follow later steps, and retrieve the final result.
Run reminders defined in the workflow and communicate a status, result, or next action when available.
Run defined approval steps, hand the process to a human operator, and continue follow-up afterward.
Stop, cancel, reopen, or perform another action only when it is explicitly defined and permitted in the workflow.
Automatic execution and human approval can be defined separately for each action.
An organization can limit BasisAssistant to specific workflows and actions, deciding when automatic execution, user confirmation, or human involvement is required.
Process Owners and IT teams can match automation to the sensitivity of each process. Not every action must be automated or approved by a person.
Authority can be configured by workflow, action, role, and user access level.
BasisAssistant displays only information that the user is permitted to view.
Protected information requires valid user identity.
Assistant actions are recorded in logs and audit trails.
User, assistant, and operator activity can be distinguished in process history.
Additional controls or human approval can be required for sensitive actions.
Human handoff can route work to operators, specialists, managers, business units, queues, or defined roles.
Information requirements can be defined for each workflow and customer scenario.
Each workflow has its own data requirements. The Integration does not require every user detail or an entire conversation to enter the process.
The organization defines what is collected, transferred, or stored. Selected structured data and a conversation summary are typical; full history is transferred only when required.
Files, images, and supporting documents can be transferred when the workflow contains the relevant fields.
Workflow data belongs to the customer and is available for retrieval or download.
Names, contact details, identifiers, request types, priorities, and destination teams are examples of structured fields.
Fields are not limited to these examples; each workflow defines its own.
The customer determines which data is collected, transferred, or stored.
Visibility, the next action, and human involvement remain governed by the workflow.
BasisAssistant can retrieve the status of an active workflow and return permitted information, keeping the request connected to the same process from start to follow-up.
Visibility is configurable. One workflow may show only a general status; another may expose permitted stages or the next action.
Handoff can include workflow data, conversation summary, current stage, and information required by a human operator. The assistant can continue follow-up after that step.
Temporary unavailability does not necessarily mean the action has permanently failed.
If Engine Workflow is temporarily unavailable, a request can be queued and retried. Users should be informed if registration or execution fails.
A unique request identifier can help avoid duplicate registration or execution. Errors and retries can be reviewed in panel logs.
The Manzoomeh team reviews technical Integration issues; workflow logic or request configuration issues are reviewed with the Process Owner and workflow team.
Workflow design and Integration implementation can be separate scopes.
The customer needs an active Enterprise environment with BasisPanel and Engine Workflow. The target workflow must be designed before the Integration is implemented.
When a workflow has not been defined, analysis and design are a separate scope, clarifying process steps, information requirements, responsibilities, permissions, and acceptance criteria.
The workflow and its required information structure must be approved.
Roles and access levels must be defined.
Business rules and permitted actions must be agreed.
Test data must be available.
Customer-side participants for user acceptance testing must be identified.
Prepare the workflow.
Map requests and data to the workflow.
Configure roles and permitted actions.
Configure the Integration.
Run technical testing.
Complete user acceptance testing.
Run a limited pilot.
Move the approved workflow into production.
Capabilities depend on workflow design, data, and permissions.
This page covers the internal connection between BasisAssistant and Engine Workflow, not a ready-made integration with external BPMS platforms.
Within Engine Workflow, each action must be defined, have the required data, and be permitted for the relevant role.
Ready-made external BPMS connections are outside this page's public scope.
Actions outside the defined workflow are not presented as ready capabilities.
Actions without the required permission are not executed.
No business outcome is guaranteed.
Complex or multi-organization workflows may be feasible depending on design, roles, data, and actions.
Only actions designed to require human involvement must be completed by a person.
No separate numeric SLA is published for this Integration.
Support levels follow the Enterprise plan and customer agreement.
Custom workflow changes or design may be a separate project scope.
The customer's Process Owner remains responsible for its workflow and business rules.
Manzoomeh supports the internal Integration between BasisAssistant and Engine Workflow. The customer owns its data, business rules, workflow design, and operational scope.
Integration maintenance is included within the Enterprise service. Changes or extensions to customer-specific workflows may be a separate project.
Workflow changes use versioning, configuration updates, and renewed testing before operational use.
Yes. The internal connection between BasisAssistant and Engine Workflow is available across Enterprise plans. Practical use depends on an active Engine Workflow, a prepared workflow, and configured access permissions.
No. It can also run actions defined and permitted in Engine Workflow, including starting a process, creating a request, routing work, creating tasks, changing an allowed status, and retrieving results.
No. Each workflow defines whether an action runs automatically or requires confirmation from a user, manager, or operator.
Yes. It can retrieve workflow status and present the permitted status, result, or next action according to the user's access level.
Only data defined and permitted for that workflow. Selected structured data and a conversation summary are typical; full history is transferred only when required.
Yes, when the workflow includes the relevant field and permits the transfer.
An Enterprise environment with active BasisPanel and Engine Workflow, a designed target workflow, and defined roles, permissions, business rules, and test requirements.
Process analysis and Workflow & BPMS Design are a separate scope. Once the workflow, data, roles, and permitted actions are defined, the Integration can be configured and tested.
No. It covers only the internal connection between BasisAssistant and Engine Workflow, not ready-made or generally available external BPMS integrations.
A failed request can be queued and retried. The user should be informed when execution fails, and errors and retry attempts can be reviewed in panel logs.
The customer owns workflow data and can retrieve or download it.
Yes. A demo can show request registration, workflow execution, permitted routing or actions, and status tracking.
Use the meeting to review the existing workflow, required data, BasisAssistant authority, and the Integration path before implementation.