How to Build a Make.com Kanban Board for SAP Focused Build

Define the role of the Kanban board before building it

SAP Focused Build should normally remain the authoritative source for the governed work item, its formal status, and the delivery information that must be reported back to SAP stakeholders. The Kanban board is a working view for teams that need to see flow, blockers, ownership, and near-term movement in a more visual format.

This distinction prevents a common integration failure: allowing two tools to own the same status without a clear rule. If a developer moves a card to Done while SAP still records the item as In Testing, the automation has to know which change is authoritative and whether the difference is a valid transition, a delayed update, or an error.

Before opening Make.com, answer three questions:

• Which SAP objects need to appear on the board: work packages, work items, requirements, defects, or a defined subset?
• Which business states should be visible to the delivery team?
• Which changes are allowed to flow back to SAP, and which are read-only on the board?

A useful board does not necessarily show every field from SAP. It shows the small set of information needed to make a decision or complete a handoff, such as title, identifier, status, owner, release, priority, dependency, and links to the source records.

Design the data contract between SAP and the board

The integration needs a data contract, even if the implementation is built with visual modules rather than code. This contract defines how a record is identified, which fields are transferred, how values are transformed, and what happens when data is missing or invalid.

Use a stable identity for every synchronized item

Each board item should retain the SAP identifier in a dedicated field, label, or controlled section of its description. Do not rely only on the item title. Titles change, may not be unique, and can cause duplicate cards when a scenario searches for an existing record.

The synchronization logic should be able to answer: “Which board item represents SAP record X?” A stable external ID makes create-versus-update decisions repeatable and supports troubleshooting when a record is moved, renamed, or reassigned.

Map business states, not just words

Status mapping is more than replacing one label with another. The integration should describe the meaning of each state and the transition rules around it. For example, a SAP status that means “approved for build” may need to map to a board column called Ready for Delivery, while a technical status such as “in process” may not tell the team whether work is blocked, active, or awaiting review.

Document the mapping in a table with at least these columns:

• SAP status and its business meaning.
• Board column or status value.
• Allowed next states.
• Owner responsible for the transition.
• Whether the change can be written back to SAP.
• What should happen when the value has no mapping.

Choose a controlled integration architecture

A practical architecture has four layers. SAP Focused Build holds the source records. Make.com handles scheduling, API calls, filtering, transformation, and routing. The Kanban tool provides the visual working view. Collaboration tools such as Slack or Microsoft Teams may receive selected notifications, but they should not become an unstructured status database.

For an initial implementation, use a scheduled scenario that retrieves only the relevant SAP records. Apply filters for project, release, work package, team, or last-change time where the available API supports them. The scenario should then search for the stable external ID on the board and either create a new item or update the existing one.

Keep the first release deliberately narrow. A one-way synchronization is easier to test because it has one direction of authority. Once the team understands the mapping and can resolve exceptions, a second scenario can be introduced for carefully selected updates from the board back to SAP.

Build the Make.com scenario in a safe sequence

Once the data contract is agreed, build the automation in small, testable stages.

In Make.com, this sequence may use HTTP modules for SAP calls, JSON parsing, filters, routers, and modules or API requests for the selected board platform. The specific modules can change over time, so the durable design is the sequence and its decision logic, not a fixed screenshot of the scenario.

Decide whether reverse synchronization is justified

Writing board changes back to SAP adds operational value only when the board captures a legitimate business decision that SAP needs to know about. It also introduces conflict handling, permissions, transition validation, and the possibility of update loops.

Before enabling reverse synchronization, define the allowed changes. A team may be allowed to update an operational owner or a readiness flag, while formal SAP lifecycle transitions may remain controlled by an SAP role. Avoid treating every board movement as an instruction to change the source record.

A safer reverse flow stores the last synchronized value, detects a meaningful change, validates that the destination transition is allowed, and updates SAP only when the record has not changed in the meantime. If both systems changed since the last synchronization, route the item to an exception queue for human review.

Use notifications to support handoffs, not create noise

Notifications are useful when they correspond to a decision, handoff, or risk. Examples include an item entering a testing state, a required owner becoming empty, a blocked item remaining unchanged, or a synchronization failure affecting a release view.

Do not send a message for every field update. Excessive alerts train people to ignore the channel and make it harder to distinguish an operational exception from normal system activity. A notification should include the work item title, stable identifier, current state, responsible owner, and links to the relevant records.

Keep the board and SAP as the places where status is maintained. Use Slack or Microsoft Teams for a concise signal that points people back to the source records and the next required action.

Control the integration in production

A working scenario is not necessarily a reliable operational system. Production readiness depends on how the integration behaves when APIs are unavailable, records are incomplete, permissions change, or a status is introduced without updating the mapping.

Start with a limited project or release and compare the board against SAP manually. Ask whether the board helps the team identify the next decision faster, whether ownership is clear, and whether the mapped statuses still represent real business states. Expand only after those answers are positive.

For a broader review of connected workflows, system ownership, and automation design, see ConsultEvo’s systems, automation and AI implementation services. Related operational examples are available in the ConsultEvo client work portfolio.

Example operating model

Consider a hypothetical SAP delivery team managing work items for a release. SAP remains responsible for the formal lifecycle. Each in-scope work item is copied to the Kanban board with its SAP ID, owner, release, and mapped status. The delivery team uses the board during daily coordination to identify items waiting for review or blocked by a dependency.

When SAP changes an item to an approved delivery state, Make.com updates the matching board item. If a team member notices that the item lacks an owner, the board can expose that gap and trigger a targeted notification. If the team later decides that a specific readiness field should be maintained from the board, that single field can be given an explicit reverse-sync rule. The rest of the formal SAP status remains controlled in SAP.

This model adds visibility without pretending that a Kanban card and a SAP work item are interchangeable. It also gives the automation a defined job: move trusted information between systems, preserve identity, and surface exceptions that require ownership.