Developer Studio: custom entities, forms, change requests, rules, notifications and audit

#Purpose and scope

This chapter covers the Developer menu (the AI Studio module's low-code surface): custom and built-in entity definitions, the form builder, governed change requests, custom applications, business rules, notification rules, form actions and audit configuration. The Developer home page lists these tools.

#Before you start

1. The Developer menu group is admin-only. The change-request surface runs and generates database DDL, so it is restricted to a superuser or the Admin role, and a portal token can never authorise it.
2. The module declares three separately activatable capabilities because they can change tenant behaviour and data models: Runtime Forms & Custom Entities (entities, form builder, applications), Governed Schema Change Workflow (change requests) and Developer Automation Rules (business rules, notifications, audit configuration). Ask your administrator which are active for your tenant.
3. Work in a development environment first and promote with an exported package.

#1. Entities and fields

1. Open Entities to see custom and built-in entity definitions. Create a custom entity, or extend an existing standard module table by choosing the target module key, entity key and table name.
2. Add fields with a snake_case name (lowercase letters, numbers and underscores, starting with a letter) and a data type: string, integer, decimal, boolean, date, datetime or text.
3. Add relationships: One-to-Many (a foreign key column) or Many-to-Many (a junction table).
4. To make an entity usable by outside users, set Portal Exposure to customer, vendor or careers, name the owner field (required), and optionally allow portal users to create rows (the owner is stamped by the server).
5. For approval, set the status field, the approval record type (default CUST-<entity key>) and mark the entity Submittable. For finance, switch on posting: choose the posting record type (default JV), the amount field and the debit and credit ledgers (or per-row ledger fields); a journal voucher is posted when an approved row is finalised.

#2. Forms

1. Open Form builder. A form has tabs, fields and grid columns that you can reorder. Regenerate rebuilds a form from its entity.
2. Save a version to keep a commit-style history with diffs, and restore an earlier version when needed.
3. For shipped (standard) forms you save a customization layout instead of editing the original.

#3. Change requests

1. Open Change requests. A change request collects entity and field changes (statuses: draft, released, applied, rolled back, failed).
2. Preview SQL first. Release a draft change request: BSuit generates the forward and rollback SQL from the entity definitions and gives it the next sequence number.
3. Apply (shown as Activate) a draft, released or rolled-back change request. BSuit runs the DDL, deploys the entities, registers permission codes, registers menu items, publishes form layouts, unlocks the objects and records the change in the applied ledger.
4. Roll back an applied change request to run its rollback SQL, set entities back to draft and deactivate the menu items. A rolled-back change request can be reset to draft.
5. Export a change request as a package and import it into another environment; the import creates a draft change request.

#4. Custom applications

1. Open Custom applications and create an application with a key (permanent, it cannot be changed), a name, icon, colour and order. A key owned by a compiled BSuit module is refused.
2. Optionally use Design with AI. It produces a review-only blueprint; accepting it creates inactive metadata and a draft change request, and does not release, apply or publish anything.
3. Activate the application. It must pass the readiness check: at least one entity, every entity deployed, a form for every entity, and every linked change request applied. The blockers are listed.
4. Export the application package to move it.

#5. Business rules

1. Open Business rules and create a rule for an entity with a trigger (before save, after save, on load, on field change or on delete), conditions in JSON and a priority (lower runs first).
2. Choose actions: set a field (supports {current_user}), throw an error (blocks the save on before save), set required, set read-only, set visible, or run a sandboxed script.
3. Use trace to test a rule against sample data without applying it.

#6. Notifications and form actions

1. Open Notifications and create a rule for any entity (built-in or custom) with a trigger event (create, update or delete), optional conditions, channels (in-app, email, SMS, push), title, body and link templates with {field} placeholders, and recipients: followers, specific users (comma-separated ids), a role, or a field holding a user id.
2. Open Form actions to add buttons to an entity’s form: start the record’s approval workflow, run a read-only sandboxed script, or call a pre-registered integration endpoint (never a free-text address).

#7. Audit configuration

1. Open Audit config and create a policy for an entity key: enabled flag, which operations to audit (creates, updates, deletes, views), fields to exclude, and retention days (365 by default).