iFlow
Move work forward without chasing the next approval
iFlow is designed to give each configured workflow clear steps, a responsible person at every step and visible progress, so requests stop waiting in chat threads and nobody has to keep asking for updates.
Does this sound familiar?
A request waits in a chat or an inbox. Nobody can easily tell who must decide next, how long it has been waiting or whether it was approved at all, so people chase each other for updates.
What it costs the business
Approvals stall, routine steps depend on someone remembering, and managers spend their time chasing instead of deciding.
Built for
- Operations directors who need routine approvals to move without chasing
- Team leads who approve requests every day
- Systems owners who standardise how work moves between teams
From problem to gain
What changes when the work moves into one place.
The situation
- Approvals stall, routine steps depend on someone remembering, and managers spend their time chasing instead of deciding.
What your team does
- Configured workflow templates
- Approver queues and notices
- Due times and escalation
What it produces
- A recorded decision on each request
- The next responsible action, with a named owner
- A view of what is waiting, with whom and for how long
What you gain
- Less time spent chasing approvals
- Overdue requests are visible, not hidden
- A record of who decided what, and when
The difference it makes
Less time spent chasing approvals
How
Designed to send each request to the named approver for its step and keep it in that person's queue until it is decided.
Overdue requests are visible, not hidden
How
Designed to show what is waiting, with whom and since when, and to flag any step that passes its due time.
A record of who decided what, and when
How
Designed so every decision is recorded with its request, and the decision starts the next responsible action.
How it fits together
What it does
- Configured workflow templates
- Approver queues and notices
- Due times and escalation
What your team gets
- A recorded decision on each request
- The next responsible action, with a named owner
- A view of what is waiting, with whom and for how long
How your team uses it
Team member
Submits a request through a configured workflow
- Output
- A request in the first approver's queue
- Next owner
- The first approver
Approver
Reviews the request and approves it, rejects it or asks for changes
- Output
- A recorded decision
- Next owner
- The owner of the next step
Operations manager
Reviews what is waiting and what is overdue
- Output
- A short list of stuck requests to act on
- Next owner
- The approver who holds each one
Inside iFlow
Configured workflow templates
Designed to define each workflow once: its steps, its approvers and the information each step needs.
Approver queues and notices
Designed to notify the named approver when a request reaches their step, and to keep it in their queue until they decide.
Due times and escalation
Designed to flag a step that passes its due time and to escalate it to the next responsible person.
Decisions that start the next step
Designed so an approval or a rejection is recorded and starts the next configured action.
Separate from Automations and Flows
iConnect CRM, which is in controlled rollout, already includes Automations and a Flows builder for conversations. Those are a separate feature, not iFlow. iFlow is designed for approvals and hand-offs between teams.
How to start / What this requires
iFlow is on the roadmap. As designed, it works inside iConnect on the same login and permissions, and needs these in place.
First step
Start with a tailored demoWe walk through your own workflow with you and confirm which of the requirements below apply to your team.
What needs to be in place
- Workflow templates agreed with your team: the steps, the approvers and the due times.
- Approvers set up with access in your iConnect workspace.
- A source of requests: a person who submits one, or an event from another iConnect product where that connection exists.
What you gain by connecting it
Selected combinations, not every possible pair. Each connection shows how far it has been proven, so you can tell what has been shown working from what is still planned.
How to read the connection labels
- Demonstrated in testing
- Shown working in our testing, on code that is not yet released to customers.
- Configured per deployment
- Depends on setup for your deployment, such as a connected channel or approved knowledge.
- Planned
- Not built yet. Shown to explain the intended workflow.
Cross-department performance
iKPI (Roadmap) would show where work waits between departments, and iFlow would route the approved improvement action to its owner. Finding a queue does not by itself authorise changing the process.
Works with
iSight (10)RoadmapiKPI (11)RoadmapSee the full workflowConnections
- iFlowiKPI
- Workflow timings for measurement
- Planned
- iKPIiFlow
- Approved improvement action
- Planned
Client review into approval
A decision recorded in iReview (Roadmap) on the right content version would start the next responsible action in iFlow.
Works with
iReview (9)RoadmapSee the full workflowConnections
- iReviewiFlow
- Recorded decision starts the next action
- Planned
Suggested solutions
Complete workflows this product takes part in.
- See where work waits between departments, act on it and measure what changesInvestigate where recorded work waits, agree an improvement action with a responsible owner and measure whether the delay falls.
- Keep every client decision with the right version and make the next action clearClients review the exact version you shared, their decision is recorded in one place, and your team can see the next action and who owns it.
Related pages
- iKPI (11)Roadmap
- iReview (9)Roadmap
- iSight (10)Roadmap
Good to know
We would rather you knew the current limits before a demo than after it.
- Roadmap: iFlow is planned and not yet offered. Request a demo to discuss your workflow.
- The Automations and Flows in iConnect CRM (Controlled rollout) are a different, existing feature. They are not iFlow.
- Routing an approval does not by itself shorten the delay. Reducing approval time is a goal to measure, not a promised result.
- Connections with iKPI (Roadmap) and iReview (Roadmap) are Planned.
Technical details
For technical evaluators: records, roles, inputs and setup, as far as current evidence supports them.
Show the technical details
- Records
- Designed around a workflow record: the request, each step, its approver, its decision and the time spent waiting.
- Permissions
- Designed so only the named approver for a step can decide it, within your company's own workspace.
- Configuration
- Workflows, approvers and due times are agreed with your team and configured for your deployment.
- What a pilot would measure
- Queue time compared with active time, overdue approvals, failed hand-offs and the time managers spend following up.
Questions and answers
What is iFlow?
iFlow is a planned iConnect product, built by iConsultants, for routing configured requests and approvals to the responsible person and showing what is waiting. It is on the roadmap.
Is iFlow the same as the Automations in the CRM?
No. iConnect CRM, which is in controlled rollout, already includes Automations and a Flows builder for conversations. iFlow is a separate, planned product for approvals and hand-offs between teams.
How is iFlow different from iKPI (Roadmap)?
iKPI, which is on the roadmap, shows where to investigate delay and measures what changes. iFlow is designed to route a configured action or approval. Finding a queue does not by itself authorise changing the process; a person decides.
Can I start using it today?
Not yet. iFlow is on the roadmap. Request a demo to discuss your workflow and where approvals wait today.
Discuss your workflow
Tell us which requests and approvals wait longest in your business today. We will reply to arrange a conversation.