Map a workflow before you automate it

Choose one process with a clear beginning and end.

Automation planning works best when the task is specific enough to describe. “Improve administration” is a broad ambition. “Move a completed intake request to the person responsible for reviewing it” is a process you can map. Start with something the team repeats and can explain using a recent example.

Define what starts the process and what counts as completion. Keep the first map within those boundaries. If another process begins afterward, note the connection without trying to redesign everything at once.

Follow one real example through the steps.

Ask the people who do the work to walk through a typical request. Record what happens in the order it actually happens, including any email, spreadsheet, shared information, or other tool involved. The aim is to understand the current process before drawing a preferred version.

For each step, capture a small set of details:

• What information arrives or needs to be entered.
• Who is responsible for the next action.
• Which tool or location holds the information.
• Whether a decision or approval is needed.
• What tells the next person that work is ready.
• What shows that the step has been completed.

Use plain language. A map that the team can review together is more useful at this stage than a complicated technical diagram.

Make decisions and exceptions visible.

A process rarely follows the same path every time. A request may be incomplete, an approval may need more information, or the usual person may be unavailable. Add those common situations to the map and describe what the team does today.

Separate routine movement of information from decisions that require a person. Sending a notification and deciding whether a request is ready are different tasks. Identifying that distinction helps give an automation a clear role while preserving responsibility for the decision.

Decide what a useful improvement would look like.

Look for repeated entry, unclear ownership, or information that does not reach the right person. Choose a practical improvement tied to one of those issues. For example, the desired change might be a consistent intake record, a clearer approval handoff, or a shared view of work that is waiting.

Discuss what information should appear in reporting or a dashboard. A useful status should reflect something the process actually records. If the team cannot agree what a status means, resolve that definition before expecting an automation to report it.

Use the map to define the next step.

Once the process is understandable, consider how tools such as Power Automate and SharePoint might support it. The map should guide that conversation: the information required, the responsibilities involved, and the steps that need to connect.

Choose a representative example and an exception to walk through with the proposed approach. Confirm how someone will review the result and where questions will be recorded. Keep the scope focused enough that the people using the workflow can understand what is changing and why.

A one-page workflow brief

Describe one process using these fields. If the people doing the work disagree about an answer, resolve that decision before building an automated version.

• Trigger: what starts the work, and how do you recognize a duplicate?
• Input: what information is required, where does it come from, and who can see it?
• Decision: who approves, what rules apply, and what happens after rejection?
• Exception: what happens when information is missing or a system is unavailable?
• Completion: what record proves the work finished, and who receives it?
• Owner: who maintains the process and receives failure notifications?

Example: a purchase request

A staff member submits the item, business reason, amount, and cost owner. A manager approves or rejects the request. The finance owner receives approved requests, and the original requester can see the outcome. Missing information goes back for correction; duplicate submissions and absent approvers have defined handling.

This is an illustrative process, not a client result. Its useful feature is the explicit decision and record at each handoff.

Estimate value without overstating savings

For illustration, 60 requests taking 10 minutes each represent 10 hours of monthly hands-on work. If a tested process reduces that to 4 minutes per request, the difference is 6 hours before allowing for maintenance, exceptions, and review. These are sample inputs, not measured FortLyn results or a financial guarantee.

Test the exceptions before launch

Include a normal approval, a rejection, missing input, a duplicate, a failed connection, and an unavailable approver in the test plan. Confirm that each case leaves a useful status and sends the right notification. Agree who can change the workflow after handover.

Explore workflow automation services, compare illustrative project formats, or review one process with FortLyn.