Integrations
Part of Building internal business apps without code
No-code apps versus automated integrations
Decide when staff need an app, when an automated transfer is enough, and when one workflow needs both.
Choose a no-code app when a person needs an interface to enter, inspect or decide something. Choose an automated integration when an agreed event or schedule should transfer data or trigger an action between systems without a new screen. A workflow may need both; decide which part each one owns.
Look for the human decision
Imagine a team receiving equipment return notices. Staff may need to review an item's condition, add a note and decide whether the return is complete. That requires a place to see and change the record; an app can provide that working view.
If a completed return then needs to update an existing inventory system, an integration may perform the transfer.
The distinction concerns the task, not the product label. A builder may offer forms and automation together.
For example, a Power Apps canvas app can provide list and form screens for records, while a Power Automate cloud flow starts with a trigger and runs actions. Those are available mechanisms; they do not determine the right design for a particular organisation.
| Ask | App is likely needed when… | Integration may be enough when… |
|---|---|---|
| Who starts the work? | A person must supply or review information. | An event or schedule can start the action. |
| What must a person see? | They need a record, status or correction path. | An existing system already gives them enough visibility. |
| Where is the decision made? | Staff must choose an outcome. | The action follows an agreed rule without a new decision. |
| What happens on failure? | Someone needs a working view to resolve a case. | An existing system has a suitable exception queue. |
An automated process still needs an owner and a way to detect failures. It can also involve people through an existing system without needing a new app.
No-code app vs Automated integration: When to use each
- Who starts the work?
- A person must supply or review information.
- What must a person see?
- They need a record, status or correction path.
- Where is the decision made?
- Staff must choose an outcome.
- What happens on failure?
- Someone needs a working view to resolve a case.
- Integration may be enough when…
- An event or schedule can start the action.
- Integration may be enough when…
- An existing system already gives them enough visibility.
- Integration may be enough when…
- The action follows an agreed rule without a new decision.
- Integration may be enough when…
- An existing system has a suitable exception queue.
Keep one authority for each fact
Write down which system owns each field. If an inventory system owns an item's location, an app might show that location while storing a separate inspection note. Letting staff edit location in both places creates a conflict unless there is a rule for reconciling changes.
For a transfer, specify its trigger, source record identifier, fields sent, destination action and expected confirmation.
If the destination does not confirm a write, its outcome may be unknown until checked. Repeating an uncertain action can create a duplicate record or notification. Recovery depends on the connected system and the operation.
Key considerations for integration reliability
- Ownership clarity
- Each field must have one authoritative system.
- Failure detection
- Automated processes still need monitoring and human oversight.
- Duplicate risk
- Repeating uncertain actions may cause duplicates.
- Confirmation required
- Destination must confirm write success before assuming completion.
Decide whether to combine them
Use an app and integration together when a person must act and the confirmed result then belongs in another system. Make the boundary visible to users: “Saved here” and “Updated in the inventory system” are different statements. Show the second only when the integration's outcome is known.
Sketch one ordinary case and one failure case through the person's screen and both systems. If the proposed app adds no useful action or visibility, use the existing interface and focus on the transfer. If the proposed integration copies facts between two editable stores, settle ownership before connecting them.
Designing a workflow with both app and integration
- Identify the human taskDetermine if staff need to review, enter or decide on a record (e.g., equipment return condition).
- Define the automated transferSpecify trigger, source record, fields sent, destination action and confirmation requirement.
- Assign ownership of each data fieldEnsure only one system owns each fact (e.g., inventory system owns location; app stores inspection notes).
- Visualise the boundaryShow users: “Saved here” vs “Updated in the inventory system” – only confirm the latter after successful integration.
- Test normal and failure casesSketch one typical case and one failure scenario across both app and systems to ensure clarity and recovery.
