The security model: classification, visibility and requirements

You set up security where you build: in Development. When you publish, it travels along to the next environments.

A new table in the module General. Give it a name under Settings.

Under Security you say how sensitive the data is. Salaries are personal data. From now on no endpoint, workflow or chat with a lower classification gets to see these rows: data never becomes less protected because someone reuses it.

A new workflow shows its settings on the right. Set it to Shared, so other modules may call it. Because it handles personal data, you demand the permission hr:read and the classification personal data from every caller. These demands travel along: whoever calls the workflow — an API, another workflow, an agent — must meet them.

Add a Table step, choose the salaries and connect the trigger to the step. Then save. On every run the step checks that the caller has at least the table's classification.

An API is the front door: one base path, one security policy. By default a consumer only gets in with an API key.

An endpoint binds one method and path to one workflow. Choose the salary workflow and save, without extra permissions. Flow refuses: this endpoint would open the workflow to consumers who do not have hr:read.

Fill in hr:read under Additional required scopes and save again. Now it works. The endpoint also takes over the workflow's classification: personal data never opens without signing in and a permission. The plain-language summary says this endpoint is stricter than the API.