Workflow, Tasks, and Approvals
When you ask Worka to do something, the workspace turns that request into work that can be tracked and controlled.
This page explains the terms that matter when you are looking at workflow activity, waiting on approvals, or trying to understand why the workspace is still busy.
What a task is
A task is a piece of work you care about.
Examples:
- build a workspace
- answer an incoming message
- prepare a release
- investigate an issue
- add a new connection
A task is usually what you will see in activity or workflow history.
What a step is
A step is one action inside a task.
A step might:
- invoke an AI team member
- call a tool
- wait for approval
- hand work to another AI team member
- publish a result into a view
One task can create many steps. A step can also create more steps after it finishes, which is why the workflow can keep expanding as Worka learns more or reaches a branch in the job.
Why tasks create more tasks
Worka does not need the whole workflow decided in advance.
For example:
- you ask for a new workspace
- Worka realises it needs a pack that does not exist yet
- it creates build work for that pack
- that build work may create review, publication, and attachment steps
- once the pack is ready, the original workspace task continues
That is normal. Worka is meant to keep moving the job forward until it is done, blocked, or waiting for you.
What you should expect to see in workflow activity
A useful workflow view should make these things visible:
- the current task
- the current step
- what just finished
- what is blocked
- what is waiting for approval
- what will happen next
You should not need to guess whether the workspace is still doing work or simply stuck.
How approvals fit in
Some steps should not continue automatically.
Examples:
- attaching a new high-risk capability
- using browser control for the first time
- granting broad service access
- publishing a shared external view with write actions
When Worka reaches one of those points, it should stop and ask for approval instead of continuing silently.
Where approvals appear
Approvals are not just local popups hidden inside one view.
They should be visible:
- in the workspace where the work is happening
- in global attention or notification areas
- in the workflow history for the task that is waiting
That matters because you may not be looking at the same workspace when an approval becomes necessary.
What happens after you approve or cancel
After you respond to an approval, the workflow should make the result obvious.
If you approve:
- the blocked step can continue
- the status should update
- later activity should show what happened next
If you cancel or reject:
- the blocked step should stop or fail clearly
- the reason should stay visible
- the workspace should not pretend the task completed successfully
How to think about retries and waiting states
Not every waiting state is a problem.
A task may be:
- waiting on a service connection
- waiting on approval
- retrying a failed step
- waiting for a pack to build or attach
- waiting for a device or runtime path to become available
The workspace needs to tell you which kind of wait you are looking at.
Example
Imagine you ask Worka to build a workspace that handles customer intake from WhatsApp and routes issues to the right internal team.
The workflow might look like this:
- create the starter workspace
- propose AI team members for intake, triage, and follow-up
- request approval for WhatsApp access
- attach the communication pack
- publish the first intake and queue views
- continue refining the workflow while the first views are already usable
If you understand tasks, steps, and approvals, you can read that history without feeling like the system is behaving randomly.