Appmint Database: Collections, Forms, Rules and Access

▶ Play video

Watch on YouTube ↗

1. Understand collections, schemas and records

Cedar & Form wants to collect design requests in a consistent form, let staff review them and keep the visitor's submission separate from the public website. You will build a Design Requests collection, enter records, add a specialist variant, configure access and connect the collection to workflow and notifications. You will also learn how to change the schema after records exist.

Use an authorised training organisation. You need collection-editing access and a second, less privileged training account for the access exercises. Public submissions use fictional project details and an email address you control. Do not enter private customer information while learning the form and permission settings.

Expand Database in the main navigation and open Dashboard. Use View Base Collections, View Custom Collections and View Sub Schemas to distinguish the built-in types, organisation-defined types and variants. A schema defines fields and the form that edits them. A record contains one saved request using that definition. Changing a form title does not create another customer request.

Open a collection's management view and read its name. Its Overview summarises the collection; Data shows the records. Public Access, API & Endpoints, Rules & Validation, Permissions, Workflow, Automation, Notifications and Connections configure different ways the collection behaves. Use this collection-specific route for settings, so the name remains tied to the operation. Generic dashboard Rules and Permissions entry points do not establish a selected collection.

Inspect a built-in collection without changing it, then return to Custom Collections. Our course creates design_requests rather than altering a built-in customer or order type. At the end, you should be able to identify both the saved schema and a particular request record by its ID, explain who can create/read/update it, and follow the work initiated by a new request.

2. Create the Design Requests collection

Choose Database → New Collection. In Collection Info, enter Name design_requests, Title Design Requests, and Description Cedar & Form service enquiries and review details. The Name is the technical identifier used by data tables and endpoints; Title is the readable label. Names accept letters, numbers and underscores, are normalised to lowercase, and must be between 3 and 20 characters. Avoid spaces and punctuation. The title must be between 3 and 50 characters.

The saved collection management screen. Check the Name before using Data, Public Access or Permissions; these settings belong to this collection.

The current replay uses the separate training collection course_requests_1003. For this lesson enter design_requests; keep your chosen technical name consistent throughout. This is the identity editor before save, not a completed record.

Return to Schema Builder to define the form. The property panel separates Elements, Properties, Theme and Magic. Elements supplies controls; Properties configures the selected field; Theme changes appearance; Magic adds interactive behaviour. If the panel is collapsed, expand it before looking for a setting.

You can use Use Template as an alternative. Inspect the template's field structure and adapt it to the design request instead of accepting every example field. Template content can replace or reshape the working schema, so apply it before investing in custom field and layout changes. Keep the blank route for the main exercise, which makes every field's purpose visible.

Save the collection using the editor's Save. If the name is already in use, choose a distinct training name and carry that exact name into all later settings. Do not solve a uniqueness error by switching to an unrelated existing collection. After saving, open Database → Dashboard, locate your collection in Your Collections, and choose its Manage button. The standalone New Collection editor does not necessarily show Manage. From management, Edit Schema returns to the builder and Data opens the collection records.

A schema editor embedded inside another form is a different context. Embedded mode keeps schema edits with its host and exposes Schema Builder, Schema Tree, JSON Schema and Form Preview. It has no independent collection record to save and no meaningful Live View. For this course, use the standalone Database collection so you can manage records, permissions and workflow.

3. Define fields, defaults and lookup choices

In Schema Builder → Elements → Form Elements, drag Text Field from the palette into the dashed canvas, release it, select the new field on the canvas and open the Properties tab. Clicking the palette item alone did not insert a field in the current walkthrough. Give each field a stable Name and a readable Title. Names become data keys; titles can change without renaming stored keys. After changing Name, leave the field selected and allow the Properties update to reach the canvas before switching tabs or saving. Check JSON Schema for the new key first. The current editor defers a name change by about one second; clicking Save immediately can precede that update. Then save and perform the reopen check in chapter 6. Use the following definition for the worked example.

Select the field, then Properties. Name controls the stored key; Title controls the readable label. The saved result is checked independently in chapter 6.

Choose controls to match the value. A textarea remains a string; a checkbox stores a boolean. Enter a numeric default as a number, not the text “two”. For selection fields, the visible label and saved value serve different purposes. Rules later compare whole_home, so keep that value stable even if you rename the label.

Add an object field property with child string fields city and postalCode. This keeps one property's details together. Add a repeatable array rooms, with an item object containing name and numeric area. Test two items, Living room and Study, rather than assuming that an array control works from an empty preview. A multi-choice field is useful for a short list of values; an array of objects is useful when each room has several attributes.

Use Elements → Collections when a field should draw from an existing collection, such as a service catalogue or office locations. Select the source collection, then inspect the resulting field's data-source configuration. Choose the source value field and label field according to what the saved record must retain. For example, a location record ID is a stronger reference than its changeable display label. Open the source collection and confirm the options actually exist.

Set required, length, pattern, numeric and item-count constraints only on controls that expose them. In Form Preview, try an empty required name and a room count of 0, then the valid values. The useful result is a field that stores the intended type and gives the user an actionable correction, not simply a red border.

4. Organise the form and its appearance

The same schema describes data and the editing form, but presentation should not change the meaning of the data. Keep basic contact details together and optional room details later. This lets staff or visitors understand what belongs in each field without changing the technical keys.

Put a field into a named tab

1. Open Schema Builder → Elements → Layout Components. Drag Tab Container into the dashed canvas. Clicking the palette alone does not insert it.
2. Double-click the initial tab 1 label, type Contact, then press Enter or select the checkmark (Save edit). A single click switches tabs; it does not rename one.
3. Select the + immediately beside the tab labels. Double-click the new Tab 2 label and rename it Project the same way. Do not use the trash icon: it removes that tab item.
4. Select the fullName field on the canvas, open Properties, and find Layout Group. Choose the entry ending › Contact. The prefix is your generated tab-container name, so it will differ from the example below. Group is a separate field; typing Contact there does not select the tab destination.
5. Assign email and consent to Contact; assign service, room count and notes to Project. Alternatively, select a tab before dragging a new field into its dashed inner canvas: the new field receives that item's layout destination. Confirm it in Layout Group.

A field belongs to one item inside a layout. Selecting the outer container alone is not enough. Moving the field changes where the form displays it, while its stored key stays fullName.

Check the preview, then the saved form

Open Form Preview. Select Contact: Your name should appear. Select Project: that field should disappear because it belongs to Contact. Return to Contact and confirm it is still present. The local example below contains only the one demonstration field; your full form should also contain the other fields assigned above.

Save the collection. Leave the builder, open Data Explorer, select your collection and choose Add Record. Switch Contact → Project → Contact again. This second check tests the saved schema instead of the builder's unsaved state. Cancel if you are only checking layout; Form Preview and an unsaved Add Record form do not create records.

The separate course_layout_1004 practice collection passed this save-and-reopen check locally. It is a focused layout example, not the completed Design Requests schema. If an existing field disappears, return to its Properties and select a valid Layout Group destination before recreating it. Check required inputs on every tab before using the form with customers.

An Accordion is an alternative for optional property details. Add its item and assign the property object to it, then test expand and collapse. A Slide Panel provides another arrangement for staged content; test its actual next/back interaction before choosing it for your final public form. Do not maintain three competing layouts around the same field. Keep one primary layout and use the alternatives on a temporary training copy.

The Pages strip also supports adding form pages. Name the first page Contact and the next Project, then inspect the Back/Next controls. Pages and layout items are distinct levels: a field assigned to a page still needs a correct destination within any layout on that page.

Open Theme to set the form's appearance. Use a readable text size, clear field labels and Cedar & Form's dark green accent. Select the form/root when making a form-wide choice; select one field for a local style. Save and reopen Form Preview at a narrow width. The final form should show every intended field once, with no clipped labels or required input hidden permanently behind a panel.

5. Create and use a sub-schema variant

A sub-schema lets Cedar & Form keep a specialist request in the same underlying collection. A Whole Home request can need an extra access note while a room consultation uses the base form. This is different from a nested object such as property: an object groups fields inside one record; a sub-schema identifies a variant of the record type.

Open the Design Requests collection's Collection Info, enable sub-schema support through the available setting and save. Choose Database → New SubSchema. In the builder, select design_requests in Parent Collection. The parent selector lists collections enabled for sub-schemas; if the parent is absent, return to its settings and saved state before proceeding.

Give the variant a distinct readable title, Whole Home Request, and a subtype identifier such as whole_home in the variant's information. Retain the common contact fields and add accessNotes, a textarea titled Access and scheduling notes. Inspect the schema tree to understand which fields belong to the variant and how the parent contributes its definition. Save the sub-schema and find it again under View Sub Schemas.

When creating a Design Requests record, choose the Whole Home variant from the available create-type cards. The selector offers Create with the subtype and a Change action when a type is selected. Enter CF-1002, the same training contact, service whole_home and access notes Weekday access after 10am. Save the record and reopen it.

Inspect the saved record's variant marker, subschema, alongside its data. The request should retain the Whole Home choice and show its added field when reopened. Do not infer that selecting service=whole_home automatically sets the record's sub-schema: one is a business field, the other is the record's schema variant. If the extra field disappears after reopening, inspect the actual marker and chosen create type before changing the parent schema.

6. Inspect the schema and save a real request

Use Schema Tree to inspect the hierarchy you created. The property object should contain city and postal code; the rooms array should contain its item fields. Use JSON Schema to inspect the same definition as structured text. This is the form definition, not a list of submitted requests.

The schema describes the field. There is no customer-entered request code in this definition.

Look for the stable property names and types. A renamed title should not silently produce a second property. If you edit JSON, preserve valid syntax and the existing UI/layout metadata. A minimal standard JSON schema may omit Appmint's controls, layout groups or rules; replacing the entire document can therefore discard useful form behaviour even when its JSON parses.

Open Form Preview and enter a representative set of values. This tab renders a preview form with an empty example data object. Use it for layout and interaction inspection; do not count it as a persisted request. Save the collection with the editor's Save, then choose Live View or the collection management Data tab.

Preview shows the input the definition produces. Entering text here is not evidence that a record was saved.

Check that the saved schema matches the editor

Before entering the full example, save the collection, leave the editor, reopen it through Database → Dashboard → your collection → Edit, and compare the field names in JSON Schema. Then open Data → Add Record and compare its labels. If you only see the generated Textfield name instead of Request code, the intended schema has not reached the record form. Do not continue filling the multi-field example against a different schema.

The current local replay verified this sequence with the disposable course_requests_1003 collection: the saved schema retained requestCode, the new record form displayed Request code, and the value DB-COURSE-1003 remained after a full page reload and reopening the record. This establishes the one-field save/readback sequence; the complete multi-field exercise below still needs its own verification.

Reopened from Data Explorer's Edit Collection Schema action after saving and reloading; this is the persisted definition, not only the editing preview.

To create the record, select the collection in Data Explorer, choose Add Record, enter the value, then choose the form's Save. To check it, reload, select that same collection again and choose the row's Edit action. Your value must still be present.

*The October 2 rename failure is retained in the research log.

For finding the collection, use the left Search collections field. Do not rely on Search records as a working row filter in the current Data Explorer; inspect loaded rows and Load More, then open the intended record and check its values or Raw JSON.

Create a request with requestCode=CF-1001, name Jordan Morgan, your controlled training email, service room, room count 2, notes Lighting and storage for two rooms, consent selected and status new. Add city Chicago, postal code 60601, and the Living room and Study array items if those fields are in your main schema. Save the record through its form.

Locate CF-1001 in the data table and open it again. Check the stored room count, boolean consent, nested property and two room items. Record its actual ID in your training notes. If the value is absent after reopening, inspect the field name, grouping path and save result. A visible input that never reaches the saved record needs correction before the public form is used.

Now create CF-1003 with one room and different notes. Both records should use the same schema but retain their own values. This second record catches an easy mistake: placing a customer's information in a schema default instead of entering it in a record.

7. Add conditional fields, calculations and form controls

Select a field in Schema Builder before opening Magic. With no element selected, the panel asks you to select one. The interactivity wizard groups templates into Field Validation, Field Visibility, Cascading Data, Calculations and Form Control. Choose a template, configure its condition, configure its action and save it into the schema.

Start with projectNotes. Use Conditionally Required so a Whole Home request requires project notes. Set the condition field to service, comparison to equals and value to whole_home; target projectNotes. Test both branches in Form Preview: room consultation can follow the chosen optional policy, while Whole Home displays the required behaviour. A condition that compares the readable label “Whole Home Planning” will miss the saved value whole_home.

For field visibility, add accessNotes to a suitable training variant or schema and use Show Field Based on Value for service whole_home. Toggle the service both ways. Check whether a previously entered access note remains in the record when the field becomes hidden. Visibility is a presentation decision; it does not establish permission to read the stored value.

For a calculation, add numeric unitEstimate and estimateTotal fields to a staff training variant. Use Multiply Values, replacing the template's example paths with roomCount, unitEstimate and estimateTotal. The expression should calculate from the current form data, for example ${parseFloat(data.roomCount || 0) * parseFloat(data.unitEstimate || 0)}. Enter 2 and 150, expect 300, then change roomCount to 3 and expect 450. This is a form calculation exercise, not an invoice or a guaranteed price quote.

Cascading Data can copy a field or derive dependent options. Start with Copy Value on a temporary contactName field using fullName as its source, then inspect the result as the source changes. For dependent location choices, configure the actual repository/options source before using Filter Options; its example repository.options is a placeholder until that dataset exists. Test changing the parent after selecting a child so a stale child value cannot silently remain.

Under Form Control, use Prevent Submission for a specific invalid condition, such as contact consent being false in this training form. Keep the message clear: Choose whether we may contact you before sending this request. Try invalid and valid submissions in Live View after saving the schema. If Magic appears correct in preview but not in the saved form, reopen the collection, inspect its saved rules and retest the exact condition and target path.

8. Configure rules with explicit triggers and actions

Magic provides guided patterns. Rules & Validation exposes general triggers, conditions and actions. Open Database → Dashboard → Your Collections → Manage for your collection, then Rules & Validation. The first New Rule opens the rule editor. The New Rule inside its left sidebar should create and select a rule; these are two different buttons, not one saved action.

Local repair verified on 4 October 2026: The previous No Rule Selected failure was repaired. The Rules entry now loads the selected collection’s schema, the inner New Rule creates a selectable row, and Save Rules persists edits. The overview count now reflects the schema’s actual rule list.

1. Open the editor with the first New Rule. Use the sidebar’s New Rule to create a rule.
2. Give it a descriptive Name. For the persistence rehearsal only, we used Course draft rule — no actions, leaving Trigger and Actions empty. This harmless fixture checks the editor/save path; it is not a validation example to rely on.
3. Select Save Rules above the manager and wait for saving to finish. Leaving before this step can discard edits.
4. Return to the collection’s Overview, reopen Rules & Validation and inspect the count. Open the editor and select the named rule again. The local check also reloaded the whole browser, reopened the collection and confirmed the same saved name.

What remains to prove: A saved rule with no actions does not protect data. Configure the real condition/action below, then test matching and nonmatching values in the form and API independently. Runtime enforcement remains pending.

Configure the conditional requirement when the editor opens a rule

Name the rule Require notes for whole-home requests. Choose a submit trigger for a submission-time check; change runs as values change, load runs on form load, and onFocus/onBlur respond to field interaction. Use a simple rule first so you can tell when it executes. Avoid creating a duplicate of the Magic rule in the final schema; use this as an alternative implementation on a training copy.

In the condition operations, choose the equality operator and compare the service field token offered by the field picker with the stored option value whole_home. Use join=and when every listed condition must hold, or or when any one condition is sufficient. In actions, choose require and target projectNotes for the true condition. Inspect the generated field token rather than guessing whether the form expects a bare key or a nested schema path.

The editor exposes actions such as hide, show, disable, require, set-property, set-value, validate, transform and a code function. Start with the declarative action. A code function is an advanced branch when the visible operators cannot express the requirement; it needs its own valid and invalid test inputs and should not replace server access controls.

Select Save Rules, then leave and reopen both the schema and the rule. The rules editor changes schema state; a listed rule is not by itself proof of server persistence. Submit one Whole Home request without notes and one with notes. Then try the authenticated API route with the same invalid data if this is intended as an enforced data rule. Browser behaviour and backend enforcement are separate observations.

The current Rules manager displays Import Rules and Export Rules, but those buttons are not wired to operations in the inspected implementation. Do not rely on them to back up or install your rules. Preserve the actual saved schema using an available working export/copy route and inspect its rules. If a rule does nothing, check collection context, save state, trigger, field token, comparison type and target before adding more conditions.

9. Manage collection metadata and lifecycle settings

Open Collection Info after the form works. Keep design_requests as the Name and Design Requests as the Title. Changing a technical name can affect data-table references, public form addresses, workflow matching and API clients; changing the readable title has a smaller purpose. Do not rename a populated collection casually while following later chapters.

Inspect the settings for workflow, versioning, indexing and sub-schema support as exposed by the collection form. Each setting has a different role. Workflow controls processing associated with records. Versioning concerns record history. Indexing concerns retrieval/search infrastructure. Sub-schema support makes the collection eligible as a parent for variants. Turning on one does not imply that the others are active or that old records have been migrated.

For Cedar & Form, preserve sub-schema support for Whole Home requests. Use the dedicated Workflow management tab to choose and inspect the effective workflow, as taught later. If you enable versioning, save the collection, edit CF-1001's notes and inspect the record's available history to establish what was retained. If no historical entry is available, keep the original export and investigate the actual runtime rather than assuming the flag guarantees a recoverable version.

After changing settings, save, close and reopen Collection Info. Compare the persisted values. Use the collection-specific Permissions matrix for record action roles rather than assuming the legacy role controls in Collection Info have identical effects.

Older documentation mentions re-indexing after bulk import and reconciling a collection. The current inspected Database interface does not establish a working control for those operations. If newly imported data appears in the data table but not search, distinguish those two results and use an established administration/support route. Do not delete and recreate the collection as a substitute for diagnosing indexing.

10. Assign roles for each record action

Open Manage → Permissions for Design Requests. The heading should identify that collection. The current Permission Matrix displays Read, Create, Update and Delete. A staff member may read requests without being allowed to delete them. Review and Approve are separate role fields under the builder’s Collection Info, not columns in this matrix; workflow approval behavior needs a separate test.

Read, Create, Update and Delete have separate role assignments. The on-screen explanation says an action with no assigned roles remains open to authenticated users; empty is not deny-all.

Choose the actual roles available in your organisation. For a training example, give a staff role read/create/update, and restrict delete to a designated administrator role. If those role names do not exist, use the equivalent real roles; typing a fictional label is not a role assignment. Keep the administrator account available while testing the second account.

The matrix's access model matters: an action with no assigned roles remains open to authenticated users according to the interface. Removing every role is therefore not a deny-all setting. Assign the appropriate restrictive role to each action you intend to limit. The Save Permissions button appears after a change; it is absent when nothing has changed. Use it after changing the matrix, then leave and reopen the collection to read the persisted assignment.

In a separate session, sign in as the ordinary training user. Read CF-1001, try the allowed update, and attempt a restricted operation on a disposable record. Record the actual result and error if denied. A hidden button is only one part of the test; the server must reject an unauthorised request too. Use API access appropriate to that second role when testing the server boundary rather than reusing the administrator's key.

Then sign in as the authorised reviewer and perform the review/approve action available through the record's workflow. If a role can edit but cannot approve, inspect the Review and Approve role fields in Collection Info and the selected workflow’s assignment rules. Reopen CF-1001 as the staff user to see the resulting state without granting extra privileges merely to make the demonstration pass.

Keep a small access table in your training notes: identity, role, action, expected result and observed result. This gives you a practical reference when Public Access changes Guest and User entries in the next section.

11. Configure public submission separately from reading

A public intake form needs permission to create a request, not permission to display every request. Open Public Access → Settings on Design Requests. Turn on Public Submit, leave Public Read off and leave Public Delete off. The three controls are independent. In this example, anyone may send an enquiry, while staff retain the authority to inspect or remove saved requests.

Public Access starts Private in this training collection. Submit, Read and Delete are separate switches; a form accepting submissions does not need public reading or deletion.

Set Success Message to Thank you. Cedar & Form has received your design request. Set Error Message to Your request could not be saved. Check the highlighted details and try again. Leave both redirect fields empty for the first test so the visitor can see the message in context. Save the settings.

Return to Permissions and inspect the resulting matrix. Public toggles derive from Guest membership in create/read/delete arrays. Saving public settings can also add User to CRUD arrays. If your staff policy required a narrower role, compare all actions again; the final matrix matters more than the colour of the Public badge.

The implementation removes CRUD permission arrays when every public toggle is off. Combined with the matrix's empty-array meaning, this can leave authenticated access open. When turning public access off later, restore the intended explicit role restrictions and repeat the second-role test. Do not interpret the Private badge as a complete access audit.

For the redirect alternative, prepare a real thank-you page on your training site and set Success Redirect URL to that exact address. Submit again and inspect the destination after the record is saved. The error redirect is a separate choice; leaving it empty often preserves useful field corrections. A redirect that loads successfully does not prove a request was stored, so always locate the corresponding record.

Before distributing the form, use a signed-out visitor session to confirm submission is available and attempts to read or delete existing requests fail as intended. If records can be read unexpectedly, correct the permissions and repeat the request before proceeding.

12. Open, embed and submit the public form

Within Public Access, Form Preview displays the schema for inspection. The management preview is rendered read-only; it is not the public submission proof. Choose Share & Embed to obtain the current form URL, submit endpoint and iframe code.

Copy the actual public form address and open it in a separate signed-out browser window. Its route includes the collection name and an organisation identifier. Keep both intact. If the page opens the wrong organisation or an empty form, compare the URL's collection and organisation with the saved collection before changing your schema.

Submit a new request coded CF-PUBLIC-1001, using the controlled training email, room service, two rooms and notes Public form test for a reading corner. Try the required-field failure first, then complete the missing value and submit once. Read the actual success message or redirect. In the staff session, open Data, find CF-PUBLIC-1001 and compare its email, service, notes and consent value. Record the resulting ID.

To embed the form, copy the supplied iframe code into an authorised training page's HTML. The code adds embed=true and an initial height of 600. Keep the real form URL; adjust the frame height only after checking the longest form and its error messages. Save the host page and open its external/public view. Submit CF-EMBED-1001 and locate that distinct record in Data. Test the narrow layout so the iframe does not hide the submit action.

The generated submit examples are not perfectly uniform: one shown endpoint includes an email path segment and orgId query parameter, while the cURL example uses a different shape and an orgid header. Use the working public form submission as the observed contract for this deployment before adapting a custom client. Do not copy placeholder field1/field2 keys into Design Requests.

If the public form renders but does not save, inspect the returned response, required fields and public-create permission. Correct the actual cause, then repeat with a new request code to separate a successful retry from the original failed attempt.

13. Use the collection API and inspect its real response

Open API & Endpoints for Design Requests. The interface offers API Key and session-token authentication and generates cURL or JavaScript examples for the selected endpoint. Selecting a real key can place its secret into those examples. Use placeholders in notes and recordings, and keep any actual credential in a private local environment appropriate to the test.

Start with Find Page, which retrieves a page of records. Inspect the generated base URL and collection path, choose a small page size and run the request in an authorised development tool. The endpoint list exposes pagination, sort direction, keyword, categories and tags. First locate CF-1001 without extra filters, then add one filter and compare the result. An empty response may be a query problem rather than a missing record.

Choose Get by ID and substitute the real CF-1001 record ID. Confirm that the response contains that ID and the expected request data. Some generated paths differ in whether they begin with a slash; inspect the final URL before running it. Do not treat a sample's syntax as evidence that the host and path joined correctly.

Check the endpoint, method and credentials before using an example. The missing-slash defect in Create and Is Unique was repaired locally. The Create screen now shows a correctly separated /repository/create path in its endpoint and generated code. The screenshot uses placeholder credentials; use the key appropriate to your own application and never put a live secret in a screenshot or public course.

This verifies the generated URL only, not a successful API write. The panel’s sample response and rate/uptime figures remain explanatory content, not measured responses from your collection.

For Create, the generated contract uses a PUT request with a body containing datatype and data. Adapt the body to your schema, for example:

{
  "datatype": "design_requests",
  "data": {
    "requestCode": "CF-API-1001",
    "fullName": "Jordan Morgan",
    "email": "[email protected]",
    "service": "room",
    "roomCount": 2,
    "projectNotes": "API test for a reading corner",
    "contactConsent": true,
    "status": "new"
  }
}

Replace the illustrative email with your controlled training address if the form contract requires a reachable address. Include additional required fields from your saved schema. Inspect the response and reopen the created record in Data. Use Update on that exact ID to change the notes, then Get by ID again. This establishes the write/read relationship.

Explore Search, Find, Find Any ID and Is Unique only with the request and response shape shown by the current deployment. A uniqueness check can help inspect a value; it does not by itself make requestCode unique under concurrent writes. Use Delete only on the explicitly disposable API test record and confirm its absence afterward. Repeat one read/write attempt with the restricted role's credentials to establish access enforcement independently from administrator success.

14. Select the workflow and follow a new request

Open the collection's Workflow tab. The toggle states either Workflows run for this collection or Workflows are off for this collection — nothing starts, requests are refused. Enabling the collection and enabling a workflow definition are separate conditions.

Workflow is off and In effect now says No workflow. Choose and enable the intended definition before expecting record processing; no workflow was started for this training collection.

Use an existing training workflow designed for Design Requests, for example Design request review, with a clear intake and review path. Select it in the Workflow dropdown, enable workflows for the collection and press Save. The empty dropdown choice, Whichever workflow lists this collection, is an alternative: it lets the server resolve a workflow whose Collections includes the datatype. Use an explicit selection for the first test so the intended definition is unambiguous.

Read In effect now after saving. This panel asks the server which workflow is effective and displays its reason. The selected dropdown value is saved configuration; In effect now is the server's resolution. If the selected workflow is disabled, use Turn it on in the Workflow Center and enable that definition through the appropriate authorised workflow controls. Return and read the effective result again.

Choose Open in Workflow Center from the effective definition. Inspect its collection association and steps before creating a new request. Then return to Data and create CF-WORKFLOW-1001 with valid contact and project details. Open the resulting work in Workflow Center and trace its starting state, assigned work and next allowed transition. Use the intended reviewer account for the review step.

Reopen the request to inspect any resulting state or recorded workflow history. A dropdown save does not establish that new requests enter the workflow, and an effective-definition response does not establish that a particular request completed its steps. Keep the request ID and workflow execution identity together.

If no work starts, inspect the collection toggle, definition enabled state, explicit selection versus collection listing, and server reason in that order. A failed effective lookup has a retry path; it should not be interpreted as a confirmed No workflow result. After fixing the actual cause, create a fresh labelled request rather than assuming old records will be enrolled retroactively.

15. Configure notification templates for record events

Open Notifications for Design Requests. The tabs On Create, On Update and On Delete separate the event that selects a template. Choose On Create for an intake acknowledgement or staff notification. An update notification is a separate decision; enabling it indiscriminately can produce messages for every edit.

Choose the event tab before selecting or creating a template. This collection has no templates on Create, Update or Delete; the screenshot does not demonstrate delivery.

Use the existing-template selector when a suitable template exists, or the new-template channel menu to choose Email, SMS, Slack, WhatsApp, Push Notification or In-App Chat. These are authoring choices; each delivery channel still needs its configured provider, sender and destination. Start with one channel already connected in the training organisation.

For an email example, open the new Email template. Its draft is scoped to the collection datatype and create event and opens in the Message Templates editor. Give it a clear name such as design_request_received. Set a subject Design request received and a short body identifying the request. Use the template editor's supported variables and preview data to insert the actual request identifier or name; do not assume an arbitrary {{field}} expression resolves.

Select the intended sender and a controlled training recipient using the template's actual addressing controls, save it, then return to Notifications. Confirm that the template appears under On Create with the intended channel. The collection view also offers Edit, Duplicate and Delete on template cards. When duplicating for On Update, explicitly inspect the event and addressing so you do not leave a second create notification by accident.

Create one new request with code CF-NOTIFY-1001 only when the training recipient and provider are authorised for the exercise. Inspect the execution/delivery status in the relevant messaging channel and the received message itself. A saved template is configuration; a sent status and the matching received content establish delivery. If the message is missing, inspect datatype/event match, enabled settings, sender, recipient mapping and provider response before creating repeated test records.

For Delete templates, use a disposable request and confirm what record fields remain available in the deletion event before depending on them in a message. Keep the main CF-1001 record for later exercises.

16. Connect automation and external services

The collection's Automation tab opens the shared Automation application. It does not itself establish a collection trigger or automatically scope a new automation to Design Requests. Read the automation name, trigger and target before enabling it.

Connections provides Open Integrations. Configure the provider in that destination; this screen itself does not connect a provider or map record fields.

For Cedar & Form, use an automation whose intended job is to follow up on a newly created Design Requests record. In its configuration, select the actual collection datatype and create event wherever that trigger is defined, and map the saved request ID, name and project notes into the supported next action. Give the automation a distinct name such as Design request staff follow-up. Inspect the whole path so a completion step does not loop back into the same create trigger.

Use the Automation application's run/execution view to exercise a controlled test. Create CF-AUTO-1001, then locate the run associated with that record. Inspect the input, the executed step and the output record or message. An enabled automation card does not demonstrate that the trigger fired; a successful run without the expected final record still needs investigation. If you are using an existing automation, edit its explicit trigger/field mapping in the automation editor rather than assuming the Database tab selected it for you.

Do not configure the same follow-up in both a notification template and an automation unless two outputs are intentional. When testing, change one mechanism at a time so duplicate messages have a traceable cause. Distinguish the collection workflow, which governs the request's work, from an automation performing a connected action.

Open Connections and choose Open Integrations. This hands off to provider configuration in Integrations; there is no demonstrated collection-specific credential form in the Connections view. Locate the provider required by your chosen action, inspect its connected account and run the provider's appropriate test through that module. Return to the same automation test and inspect execution again. Store credentials only in the integration configuration, not in schema defaults, public form HTML or notification text.

If you have no connected provider or suitable automation yet, retain the saved collection and use the dedicated Automation/Integrations course to build that dependency. The Database outcome at this point is an explicitly mapped handoff and an inspected execution, not a promise that opening Connections has synchronised data.

17. Import, export and transfer selected records

Open Data to inspect existing requests before importing. Export a small, non-sensitive sample using the collection's Export/Export Data action and open the downloaded file. Check the file's actual format, field names and record IDs. A completed download is useful only if the contents represent the collection you intended. The collection dashboard export and the data-table tools may expose different options; use the format actually offered by the current control.

From Database, choose Import Data, then Start New Import. Select a supported source and format, inspect the parsed preview, choose the existing design_requests collection and map incoming columns to its fields. Start with two rows, CF-IMPORT-1001 and CF-IMPORT-1002, using valid service values, numeric room counts and consent booleans. The preview should show two records, not one long line caused by a delimiter mismatch.

At the Summary, read the source type, format, count and target collection. Under Before you import, turn on Validate only for the first pass. This requests validation without writing records. Finish the validation run and inspect every row error. Correct invalid service values or required data in the source and repeat until the report matches your intended import.

To import and save the records, turn Validate only off. Choose the matching policy under Update existing records. Always add a new record can create duplicates when you rerun a file. Match on a stable field such as requestCode only if your data guarantees its intended identity, or use Record id for an export being reimported to update its original records. Run Finish - Import Data, inspect the report and reopen both requests in Data. Check values rather than relying only on the count.

For an organisation transfer, tick the specific training rows in Data and choose Send to another organization. The transfer builder receives the datatype and selected IDs. Read What goes and ensure it contains those rows, not the whole collection. In Where it goes, enter the actual destination organisation ID and wait for it to resolve to the correct name. Add a reason explaining the test.

Send now creates a copy request; the current interface states that nothing moves until the destination accepts. Track it under Org Transfers. A receiving administrator has an acceptance step and the copy runs afterward. Demonstrate receipt only with an authorised second training organisation, then inspect its records and the transfer status. A sent request is not a completed transfer, and the source records are not described as moved or deleted.

18. Change a populated schema and remove test material

Cedar & Form now needs an optional preferred contact time. Add a string field preferredContactTime with title Preferred contact time. Leave it optional for the first revision because existing requests have no value. Save the schema, reopen CF-1001 and confirm that the new field is available while its original notes, service and room count remain unchanged.

Enter Weekdays after 3pm on CF-1001 and save. Open CF-1003 without changing it. It should still be readable even though it has no preferred contact time. Then create a new request with the field filled. These three cases—updated old record, untouched old record and new record—show how the schema change affects existing data.

Renaming a field's Title is different from changing its Name. If you change projectNotes to a new data key, old records may still store projectNotes; a display change is not a data migration. Before such a change, export a small representative sample, identify every rule/template/automation that references the key, plan the data update, and test on training records. Inspect raw saved data if a value seems to vanish from the form.

For a new required constraint, inspect existing records before enforcing it. A field that was optional yesterday may make an unrelated edit fail today. Backfill the missing values where appropriate, then add the constraint and test both old and new records. Keep the previous schema and sample export available for recovery.

Deleting a record and deleting a custom schema are separate operations. In Data, delete only a disposable request and confirm its ID is gone while the collection and other records remain. A schema deletion removes the custom definition; it must not be described as reliably purging every stored record. Use the explicit operation matching your goal and read its confirmation before proceeding. Preserve the working Design Requests schema, CF-1001 and the Whole Home variant for the final exercise.

If a post-import search is empty while direct data access finds the records, keep the import report and record IDs. Do not use an undocumented re-index or reconcile route. Use an established administration path to investigate the search layer without destroying the stored requests.

19. Diagnose failures and complete a related request

Use the saved request as the centre of diagnosis. If the form looks wrong, inspect the schema and layout. If data will not save, inspect validation and the response. If staff cannot open it, inspect identity and permissions. If follow-up does not happen, inspect the effective workflow, notification or automation execution. These layers can fail independently.

A field that disappeared after a layout edit usually calls for checking its layout item, page and visibility condition. A field that appears but loses its value calls for checking its Name and the saved record. An email error on every input calls for checking the rule's actual target and condition, not disabling all validation. Correct one cause and retest the same input before changing unrelated settings.

A staff user who gained more access after a Public Access change needs a before/after comparison of the permission arrays. Reapply the intended action roles, save and test in the separate session. Do not clear all roles in the hope that it denies access. If a public form accepts a request but the user sees an error, locate the request before retrying so you can avoid an accidental duplicate.

For your independent task, add Preferred contact method with values email and phone, then add a phone field required only when phone is selected. Create CF-PRACTICE-1001 through the public form with email selected, and CF-PRACTICE-1002 with phone selected. Test the missing-phone branch before correcting it. Find both saved records, inspect the selected contact method and follow the intended workflow for the second request.

The checkable result is a saved schema that renders correctly, two records retaining distinct valid values, public creation without unintended public reading, role-appropriate staff access and a traceable processing result. Export those two training records and inspect their fields. A future edit to this collection should preserve these relationships: stable data keys, usable form controls, explicit access and an observable handoff to the work that follows.

Current replay limit: collection creation and a single text record save/readback were exercised locally. The full multi-field example remains pending. Complete the schema check in chapter 6 before the full exercise; public submission, API authorization, rules, import/transfer, notifications and workflow results still need their own replay.