Request an Architecture Briefing

Defined implementation

Keep approvals moving with fewer manual follow-ups.

One workflow runs live from end to end: the approval rules, the awkward cases, a history of who approved what, and an alert when something fails. It is tested on real cases and handed to a named owner who can change it.

PricePrice fixed after a short scope call.

DeliveryThe proposal names the start date, the change windows and the completion date before anything is agreed.

Fix This Workflow Review scope & terms Try onboarding & offboarding All automation services

Interactive sandbox / Employee lifecycle

One request.
A workspace ready for what’s next.

Set up a new colleague or close access when someone leaves. Approve the plan, run it and inspect what changed.

Ready to try

Working demonstration with fictional records. No live systems are connected. The plan uses fixed rules, not a live AI model. Switching examples or reloading clears the workspace.

  1. Request
  2. Review & approve
  3. Apply & check
  4. Handover

02 / Change plan

A request becomes specific actions.

Start with the sample request.
The plan will name each system, the change and the result to check.

AccountAccessMailboxIT task

03 / Sample workspace

See the records change.

Local sandbox

Entra ID

No account

No sessions

Groups & workspace

No memberships

No access

Exchange Online

Not provisioned

Sample record · no live connection

IT work queue

No task

Physical device work is handled by IT

What a client build adds

Real integrations, verified access, agreed retention rules, durable run history and tested alerts. You receive the workflow, acceptance results and an owner walkthrough. AI is added where interpreting a request helps; access changes still follow approved rules.

Meet the person responsible for delivery.

Alwatheq Zboun leads the agreed work. A sample shows the format; the statement of work defines your deliverable and acceptance checks.

Engagement context

When this engagement applies.

One process still runs on emailed spreadsheets, chased approvals, and the same data typed into two systems.

Scope considerations

  • One workflow, end to end
  • Premium connector licensing is yours
  • Handed to a named owner

The defined work

Engagement scope.

  1. 01

    Where more than one routine is in the running, each candidate is written up with the hours it costs today, and the one built first is chosen from that rather than from who asked loudest.

  2. 02

    The process is mapped as it really runs, including the exceptions people handle by hand and never mention.

  3. 03

    One workflow is built in production: the approval rules, the routing, and the data written back to the systems of record.

  4. 04

    Exception paths are built too — the rejection, the escalation, the missing-field case — because a workflow that only handles the happy path pushes the hard cases back to email.

  5. 05

    Audit history is turned on so the process can answer who approved what, and when.

  6. 06

    Failure alerting is configured and pointed at a real destination, so a broken run is noticed by a person rather than by the client waiting on it.

  7. 07

    The process is tested with real cases from the business, and handed to a named owner who has been walked through maintaining it.

Acceptance

Completion has an agreed standard.

  • The workflow runs in production against real cases

  • Every agreed exception path has been triggered in testing and behaves as designed

  • Audit history records who approved what and when

  • Failure alerts fire to an agreed destination and have been tested by forcing a failure

  • User acceptance testing is signed off by the business owner of the process

  • A named owner has been walked through maintaining and changing it

Commercial basis

Price, scope and timing are considered together.

Engagement price

Price fixed after a short scope call.

The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:

What determines the scope

  • Whether the process is already chosen, or the candidates have to be costed first
  • Whether the process needs reporting on top of it — a dashboard of what it is doing, built and handed over
  • Number of approval steps and decision branches
  • Number of exception paths that must be handled in the flow
  • Which systems are connected, and whether they need premium connectors or a custom API
  • Whether historical data has to be migrated into the new process
  • Whether the client team is trained to build the next one themselves

Delivery calendar

The proposal names the start date, the change windows and the completion date before anything is agreed.

How engagements work

Scope & responsibilities

The full engagement boundary.

Review the exclusions, required client participation, change controls and operational handover for this engagement.

Exclusions
  • Premium connector or Power Platform licensing
  • A second workflow — each is scoped and priced on its own
  • Custom application development outside the Power Platform and Microsoft Graph
  • Ongoing workflow administration after handover
  • Business-process redesign, new approval authority or operating-policy changes. Comparing candidates and mapping the agreed process does not include redesigning it
Client responsibilities
  • Name the business owner of the process, who signs off acceptance
  • Provide the real cases used for testing
  • Provide or license any premium connectors the design requires
  • Confirm the approval rules, including who can approve what and to what value
  • Own end-user communications and training
Change and rollback method
  • The workflow is built and tested away from your live system first, then moved across. It never goes live by being edited in place while people depend on it.
  • Go-live runs in parallel with the manual process for an agreed period, so the first real failure has a fallback that already works.
Operational record and handover
  • Where the process was still being chosen, the costed list of candidates and why the built one won
  • The process map, as it really runs, including the exceptions
  • The workflow itself, documented so the team can change it
  • The test record, including every exception path triggered
  • The alerting configuration and its tested destination
  • The signed acceptance and the named owner

Before you commit

A clear first step.
You stay in control.

Start with the problem and the result you need. The initial fit conversation is free and does not require access to your systems.

Check client feedback on Upwork ↗

Prefer to contract through Upwork? Contact Alwatheq there. Existing Upwork engagements continue through Upwork.

Who will actually do the work?

Alwatheq Zboun leads the scope, technical work and handover. If a specialist collaborator is needed, their role is agreed with you before work starts. Your proposal names the responsibilities and delivery windows.

What happens before you get access?

We agree the scope, fee and completion checks in writing. Access uses named accounts and only the permissions the work requires. Approved access is reviewed and removed at handover.

How do we know the change worked?

Your scope defines the pilot, test cases and acceptance checks. Results and exceptions are recorded. Recovery options and their limits are agreed before production changes; a failed check is addressed before the next approved stage.

Will we need an ongoing retainer?

A defined project can end at handover. Your team receives the agreed configuration records, runbook and walkthrough. Any limited support period is written into the proposal; ongoing support or additional work is a separate agreement.

Discuss the fit ↗Read the delivery process ↗

Discuss this engagement

Put the scope in context.

Describe the problem, systems and deadline. Alwatheq will review the fit and the scope questions before preparing a written proposal.

Fix This Workflow