Planning backends and integrations: which rules must the server know?

An employee clicks “Approve quotation”. The server needs to check whether all required information is present and whether she is allowed to approve this draft. What looks like a single button needs rules for the stored transaction.

When can the quotation be approved?

Staying with this fictional approval process, write down which information is required and which role may approve it. What happens to an approved quotation if someone changes the price? Questions like these belong in the feature description.

The MDN introduction to server-side development explains data processing and dynamic responses on the server. For your brief, the key question is which tasks already exist and which need to be added.

Distinguish login from permission

Logging in identifies a user. It does not automatically grant access to every record. In this example, a separate check must establish whether the person may edit this particular draft. Hiding a button does not replace that check.

A small role matrix helps: put actions in rows and roles in columns. Record who can read, change and approve. Add whether a permission applies only to a person’s own or assigned transactions.

Describe the interface as a contract

Frontend and backend need shared expectations. Which data is sent? What does a successful response look like? What comes back when information is missing? An API description makes these questions testable.

An external service adds another dependency. If it initially only accepts a task, the interface must not present that as a completed process. For repeated calls, establish whether they create new records or recognise the same transaction.

Define a small scope completely

A single new rule may fit the backend feature service. An existing data area with new access methods may need a dedicated API. Connecting to an external service is an API integration.

When considering a customer portal or internal tool, check which of these tasks are already included. Have the affected views and server functions named in the quotation so that you do not commission the same work twice.