Workflow automation · Ireland · Delivered from Spain
Keep approvals moving with clear owners and decisions.
An approval becomes difficult to manage when the request sits in one inbox, the latest version lives in a spreadsheet and the next person cannot see whether work can begin. Automation starts with making that decision clear.
Intelidatia designs and builds custom systems around business operations. We work remotely from Spain, in English, with Irish teams. We start with the process and the tools already in place, then agree what to keep, configure, connect or build.
Define the decision before automating the reminders
Choose one recurring request. Identify who submits it, who may approve it, which information they need and what happens after their decision. Give the team a shared answer to four questions:
- What is the current state of this request?
- Who owns the next action?
- Which version is being reviewed?
- What prevents the request from moving forward?
A reminder can help someone act. It cannot supply missing information, grant approval authority or decide whether changed work still fits the original approval.
Map one approval before you automate it
Use this spreadsheet-ready approval map to describe one concrete request that needs a decision before anybody carries out the work. It is available without a form and can be used without hiring Intelidatia.
One row represents one transition from one state to the next for one identified version of a request. Submission, approval, authorisation for execution, execution completion and closure therefore occupy separate rows. An approval records a decision; it does not prove that the work was authorised, completed or closed.
Start with a small, reviewable process
- Choose one bounded request with a clear start, decision and result.
- Describe one normal example and the recurring exceptions without copying personal or confidential data.
- Assign the requester, approver, execution owner and next-action owner as roles, not names.
- Fill one transition per row until every decision has a defined output.
- Walk the map with the team and check authority, versions, follow-up, evidence and every non-terminal state.
- Decide whether to keep the documented process, configure a tool, integrate existing systems or evaluate a focused custom component.
A complete request can move from submitted to approved, then separately to authorised_for_execution, execution_completed and a closed state. If the request changes after approval, preserve the earlier decision, mark that version as superseded and obtain a new decision before executing the changed scope. If an approver is absent, use only an explicitly authorised substitute; otherwise keep the request pending or escalate it. Silence is not approval.
Dictionary of the 27 fields
| Field | Requirement | Meaning |
|---|---|---|
| map_id | Required | Identifier shared by every transition in one mapped path; use a non-personal reference. |
| transition_id | Required | Unique identifier for this transition. |
| sequence | Required | Whole number used to order transitions inside a map. |
| request_type | Required | Bounded category of request, such as Internal purchase request. |
| process_start | Required | Observable event that starts this process. |
| expected_process_result | Required | End condition for both positive and negative outcomes. |
| request_id | Required | Non-personal reference for the request. |
| request_summary | Required | Short operational description without personal or confidential data. |
| request_version | Required | Version covered by this transition and any decision it records. |
| supersedes_version | Optional | Earlier version replaced by this one; leave blank when there is none. |
| required_documentation | Required | Documents or information needed for this transition; use None required when agreed. |
| requester_role | Required | Role responsible for presenting and correcting the request. |
| approver_role | Required | Role normally authorised to approve or reject; a substitute must be explicitly authorised. |
| execution_owner_role | Required | Role responsible for carrying out approved and authorised work. |
| from_state | Required | State before the event or decision. |
| trigger_or_decision | Required | Observable event or decision that causes this transition. |
| decision | Required | Recorded outcome, such as submitted, pending, approved, rejected or closed. |
| decision_conditions | Required | Conditions that must be true before the transition is valid. |
| to_state | Required | State after the transition. |
| next_action_owner_role | Required | Role responsible after the transition; use None — terminal state only when appropriate. |
| follow_up_point | Required | Deadline, review point or event that prompts follow-up; state when none remains. |
| exception_type | Optional | Short category for the exception handled by this row. |
| exception_owner_role | Required when exception_type is set | Role responsible for resolving or escalating the exception. |
| recovery_action | Required when exception_type is set | Safe action that moves, holds, corrects or closes the request. |
| evidence_to_close_transition | Required | Record needed to show that this transition, not the whole process, is complete. |
| terminal_state | Required | true only when this version and path require no next action; otherwise false. |
| notes | Optional | Assumptions or clarification; do not store personal or confidential data. |
Synthetic example and limits
The accompanying purchase-request example is entirely synthetic. It uses fictional references and roles. Its timings and thresholds are illustrative assumptions, not universal purchasing policies, Intelidatia terms or evidence of a client implementation.
The map is a planning aid, not executable software, an approval engine, a guaranteed audit trail, a permission mechanism or proof of legal or regulatory compliance. A documented manual process may be enough when volume is manageable, ownership and exceptions are clear and follow-up is reliable. Evaluate a tool only when the map reveals a repeated, valuable problem that the team needs to control more consistently.
An approval from request to handover
Illustrative example — synthetic process, not a delivered client project. A service team needs an internal approval before starting additional work for a customer. The roles and rules below are proposed design choices to discuss during discovery, not an existing Intelidatia product.
| State | Owner of the next action | Rule for moving forward |
|---|---|---|
| Draft | Requester | Add the work description, customer reference, requested date and current version; then submit. |
| Awaiting review | Named operations approver | Review that version. Approve it, decline it with a reason or ask for more information. |
| Information needed | Requester | Correct the request and resubmit a new version for review. |
| Approved — awaiting handover | Delivery coordinator | Check the approved version and acknowledge that it can enter the work queue. |
| Ready for delivery | Delivery coordinator | The approved request has reached the work queue. This does not mean the work is complete. |
| Declined or withdrawn | Requester | Read the reason or close the request. A revised request must go through review again. |
The request record would hold its reference, current version, state and responsible person, alongside the decision, decision-maker and time. Those fields help the team follow what happened; they do not, by themselves, establish a legal audit or compliance guarantee.
Handle the exceptions explicitly
The approver is away. Keep the request awaiting review and flag it to the process owner. An authorised person may assign a named substitute; record the reassignment. A reminder or elapsed deadline must not silently approve the request.
The work changes after approval. Preserve the earlier decision against its version. Return the changed request to review and prevent it entering the work queue under an outdated approval.
The handover fails. Keep the request approved but awaiting handover. Show the delivery coordinator what needs attention. Do not mark it ready simply because an email was sent.
Before any build, agree acceptance examples: an unauthorised person cannot approve; a changed version needs a new decision; and an approved request stays visible if the next system is unavailable. These are proposed checks for the agreed scope, not claims that this illustrative flow has been built or tested.
Use the simplest approach that covers the whole process
Your existing software may already support forms, approvals and reminders. Configuration can be enough when it covers your roles, exceptions and ownership needs. If a critical handover falls between tools, an integration may be the missing piece. A custom internal tool becomes an option when the agreed process cannot be handled adequately by those choices.
Compare custom and off-the-shelf software. If the main problem is moving approved information between applications, explore software integration. If the team needs a shared place to manage records and permissions, see internal tools.
Relevant work we have delivered
For CP Alburquerque in Spain, we built a system connecting membership, access, matches, ticket-office records and reporting with role-based permissions. It demonstrates connected operational areas and controlled access. It is not evidence of the approval process illustrated above or of delivery for an Irish customer.
Bring one real workflow to the conversation
Tell us where a request starts, who decides, which tools are involved and what happens when the normal path breaks. A description is enough to start; do not include customer records or passwords.
The first step is a free 20-minute fit conversation. We reply in English within two business days. For a complex or unclear process, we may recommend the Operational Workflow Sprint to map the work and agree a first-phase decision. The sprint does not include full development, live data migration or production automation.
Review the sprint scope, price and exclusions.
Discuss your approval workflow