Appmint Administration Essentials: Settings, Locations, Activity, Logs, Trash, Blacklist and Data Transfers

Written course script · documented draft · Live event verification pending

What you will learn

Activity Feed helps you inspect recorded events across your organization. We'll find an event, narrow the list and open its details so you can identify what happened, who was involved and which record to check next.

Start with a question you can check: which recorded event relates to a particular item? Keep the item’s name, collection, complete record ID and approximate change time beside you. If you do not know its ID, open the item in its original module first. Activity Feed is useful for inspecting existing evidence; it is not proof that every module records every action.

1. Open the feed and read its scope

Open Activity Feed from the App Root menu. Wait for the list to finish loading. A failed request displays a retry state instead of a valid empty list; choose its retry action or Refresh after correcting the connection/access problem.

Read the four figures separately:

The total comes from the server. These two counts describe only this page, so zero errors here doesn't mean there are no errors anywhere in the organization.

The list requests 50 records per page. Use Next and Previous when pagination appears. A recent event missing from the current page may require a search or a different page; do not equate one visible page with all retained activity.

2. Search and combine filters

Enter an identifying term in Search activity… and press Enter. Typing alone does not run the current search handler. Inspect the returned entries.

Use All Actions to select a recorded action and All Types to select a datatype. Filter changes reset the page to 1 and reload. Read the remaining search text as well: it is combined with these filters.

The current dropdown choices are derived from values in the loaded page, not from a complete organization-wide catalogue of all possible actions and datatypes. If the value you need is absent, clear the filters, inspect another page or use a known search term. Do not teach the menu as an exhaustive audit-event taxonomy.

The search handler does not explicitly reset an existing later page. If a targeted search unexpectedly returns no results while Page is greater than 1, move back to the first page before deciding the event is absent. Restore All Actions and All Types to remove those constraints.

3. Read an event and open its detail

Concept illustration: Carry the same organization, record identity and time through the investigation. A feed entry is not a substitute for the current state of its target. This is not an application screenshot or evidence that the action has run.

Select the matching event card. The Activity Detail drawer opens.

Use the fields actually present:

1. Read Action and Data Type to identify the kind of recorded event.
2. Check Author against the person or process you expected.
3. Read the full Record ID. The list may show only its trailing characters.
4. Check Status and Timestamp, taking the displayed local time into account.
5. Inspect IP Address and User Agent only if the event provides them.
6. Expand your review to Full Data to see the complete stored record and any event-specific payload.

The list got us to the right event. Here we can see its full record ID and payload. We'll use that identity to inspect the original item rather than guessing from a similar name.

Fields with no value are omitted. An absent author or IP field is not a claim that an anonymous action occurred; the event may not have stored that information.

Do not show secrets or private customer payloads in a screenshot shared with Support. Use a controlled event with useful but non-sensitive values, and inspect Full Data before capture.

4. Follow the evidence back to the module

Keep the event's datatype and complete record ID. Close the drawer and open the module that owns that record. Find and inspect the matching item. Compare its current status and relevant fields with the event.

The current detail drawer displays information; it does not implement a universal “Open source record,” rollback or replay action. Use the module menu to open that original record. An event's success label is not a substitute for checking the business result there.

For example, a recorded change can explain why a request reached its current state, but it is not the request itself. Later changes may have occurred after this event. Use the source record's own history where that module provides one.

5. Refresh, recover and report a useful finding

After a new controlled action, return to the feed and choose Refresh. Keep the search and filter scope visible. The page does not establish a live streaming feed merely by being open.

If an expected event is missing, check in this order: correct organization, current filters, first page/search, source action result and whether that module actually emits this activity type. A failed load needs recovery; a successful empty result needs scope checking.

For a reproducible issue, provide the action time, datatype, record ID, expected event and actual result through Support. Include the error text if a request failed. Share only the relevant redacted event fields, not an unreviewed full payload.

There is no export, edit, delete or undo action in this Activity Feed interface. Do not add those operations to the course because a generic activity table exists elsewhere.

Limitations and checks

Use Activity Feed to narrow a question to a specific recorded event, then check its full identity and the original record. Keep page-level counts and missing event coverage in mind when interpreting the result.

Source reviewed: components/activity-feed/app.tsx, its directory and the sidebar entry. Required live proof: known event emission, search on later pages, filter options, detail payload, refresh and source-record comparison. Current findings: page-derived filter choices and search retaining a later page can make discovery confusing.

Overview

Appmint Settings holds organization-wide defaults. It is one saved settings record, not the gateway catalogue or a personal preference screen. We will change a controlled value, verify its consumer and inspect the specialized groups without confusing stored configuration with a working integration.

1. Read and save the organization settings

Concept illustration: Choose the right scope before changing a value. Save, Reload and compare the actual consuming feature — not just the form. This is not an application screenshot or evidence that the action has run.

Why this matters

The screen loads base-setting and preserves its identity on save. A load failure must not be treated as a new empty organization configuration.

Follow these steps

Open Configuration → Settings with the required admin menu access and wait for the form. If Settings failed to load appears, use Retry; do not create substitute values. Inspect the read-only Setting Name and Org Id. Review System Email, System Phone, Default SMS Number, additional Emails/Phones and Address. Change one controlled value, Save, wait, then Reload and check it. Reload also refreshes contact-helper state.

Check the result: The stored value survives refresh without replacing unrelated settings.

Reload versus Cancel

The current Settings form's Cancel callback only logs its input; it does not implement restoration of the last saved record. To abandon an unsaved edit, use Reload, then compare the displayed values with the original saved values. Reload intentionally rereads base-setting and refreshes contact-helper state. Save first only when you actually want the draft persisted.

Keep an existing non-sensitive value noted before editing and change one field at a time. This shared record includes defaults used by other modules: success on Save establishes persistence, while a scheduling, notification or sign-in consumer needs its own verification. Do not change the organization's only recovery contact or sign-in requirement merely to demonstrate the Save button.

No matching Appmint Settings screenshot was available for this review. BusinessMade or AI Employee settings captures are different screens and are not substituted here.

2. Notifications and social synchronization

Why this matters

Notification copies are distinct from message templates and sending providers. Current settings do not choose a gateway or notification template here.

Follow these steps

Expand Notification Copy To for Order, Reservation or Event. Inspect Enable, To and Delivery Type and configure a controlled recipient for a prepared test only. Save and verify a real resulting notification through that module. In Social Media Sync add the intended Platform, Account Id, Sync types and Config. Choose only scopes supported by the connected account and verify actual synchronization separately. Do not treat the list of possible sync types as proof that every provider implements them.

Check the result: The intended copy or synchronization result is observed rather than inferred from a saved row.

3. Scheduling and time-off defaults

Why this matters

Named shifts and operating hours give staffing screens reusable definitions. A staffing target is not necessarily a hard capacity limit.

Follow these steps

Open Staff Scheduling. Add a Shift time with Id, Name, Start and End in 24-hour HH:mm, unpaid break minutes, Roles and Colour. An end earlier than start represents overnight. Set People needed and optional Sub-divisions with People wanted. Configure Days it runs using weekdays for weekly patterns or cycle-day indices for cycles; inspect each day’s override hours, headcount and Off flag. Set Operating hours, Schedule pattern, Cycle length/start where relevant, Plan ahead by and period movement/start. Save and inspect the staffing consumer. In Time off & leave choose counted units, leave year/fiscal start, working days, Who is HR, approval flow, escalation/digest, job levels and public holidays, then verify a controlled request.

Check the result: Consumers show the intended defaults and requests route according to verified rules.

4. Bank sync and marketplace settings

Why this matters

Organization defaults can be overridden by a connected bank. Marketplace configuration and bank refreshes are not the same task.

Follow these steps

In Bank Sync inspect Auto-sync, Pause all syncing, Transaction sync, Balance refresh, Honor bank push and Apply to new banks. Save the intended controlled change and compare the connected bank’s own override before expecting a job. In Stowbo Config inspect Take rate, Minimum payout, Payment gateway, Hold on a cart, Customer app URL and Stowbo site. Change only a configured rehearsal marketplace and test its relevant consumer.

Check the result: A consumer’s effective configuration is understood, and no financial action is implied by editing a field.

5. Security settings and recovery

Why this matters

Organization-level security requirements differ from a person enabling their own second factor. Instant card/employee-ID login also differs from a PIN challenge.

Follow these steps

Inspect Passcode Login and Passcode Login Mode, comparing passcode with instant. Use controlled staff accounts to verify the chosen mode. Inspect required 2FA for Users and Customers, available methods, new-device authentication and new-device login alerts. Preserve an administrative recovery path before enabling a requirement. Save, reopen and test a separate controlled account; do not use the sole administrator as the first test. Restore the intended value if the consumer fails and retain the actual error.

Check the result: Effective sign-in behavior follows the verified setting; a saved switch is not proof of enforcement.

Troubleshooting and recovery

Read the actual error and inspect persisted state before retrying a create or other write. Keep the selected organization, record and operation visible. A saved configuration, permission, provider connection and working consumer are separate checks; verify the one the lesson claims. Reopen after saving and compare a controlled alternate/failure path where the chapter calls for it.

Next steps

You can now follow the module’s setup and check its result. Use the relevant chapter for an alternative, and verify the actual consumer before treating configuration as complete.

Limitations and checks

SettingView and installed SDK SettingSchema inspected. Some schema groups depend on dedicated provider/modules and require live consumer tests. No configuration, messages, syncs or security requirements changed here. Current schema explicitly removes gateway/template selection from base settings.

Overview

Appmint Business Locations keeps a branch’s identity, address, tax/time settings and checkout equipment together. We will create two distinct locations and check that choosing one branch does not overwrite the other.

1. Create the location identity

Why this matters

The slug is the stable internal identity; Title is the customer-facing name. Choose the type before entering a physical address or a virtual link.

Follow these steps

1. Open Configuration → Business Locations → Add location.
2. Under Identity, enter a unique Slug (name), such as course-print-main, and Title, such as Main Print Room. The slug is the reference other modules use; the title can be readable to your team and customers.
3. Choose Type → Address for a physical branch. Enter Street1, optional Street2, City, State/region, ZIP/postcode and Country. Virtual and Website instead use a link; they are different location types, not instructions to build a site here.
4. Choose the intended Status and optional Description. Continue to tax/timezone below before Create location. Use the business's real settings rather than copying sample tax values from a screenshot.
5. Refresh the list, search the slug or title, choose Edit and confirm the saved fields. Create the second branch only after this first readback succeeds.

Historical empty form showing Address/Virtual/Website choices and address fields. Pale example text is not a saved address or a recommended tax rate.

Check the result: The record retains its identity and the appropriate physical/virtual fields.

2. Set tax, time zone and on-site clocking

Why this matters

The location’s time zone affects the calendar day of financial records. A blank zone falls back to the business profile. On-site clocking coordinates are separate from the postal address.

Follow these steps

Open Tax & time zone. Enter the applicable Sales tax rate (%) and Tax label from the business’s actual setup; use Time zone search or the browser-zone shortcut only when it matches the branch. For Clocking in on site enter Latitude, Longitude and Allowed area (metres) when a geofence is intended. Zero or blank means no check here according to the current hint. Save and inspect the persisted values before testing a controlled clock-in or transaction.

Check the result: Stored settings match the branch; date/tax/geofence behavior requires its corresponding live operational test.

3. Assign the location’s receipt equipment

Why this matters

Printer choices belong to this location’s checkout behavior. Check printer falls back to receipt printer; cash drawer can fall back to the receipt printer’s RJ12 connection.

Follow these steps

In POS settings choose Receipt printer, Check printer and Cash drawer from the configured devices. Set Auto-print receipt on settle and Open drawer on cash tender intentionally. Enter Tip prompt, Closing line and comma-separated Copy labels as needed; blank closing line defaults to Thank you and blank copy labels means one copy. Save and reopen. Run a controlled location-specific print/check/cash-settle test through POS and verify physical output.

Check the result: Correct equipment produces the intended copies; a saved device ID alone is not a physical proof.

4. Operate and compare multiple branches

Why this matters

A second branch needs a second record. Organization-wide viewing and a current-location filter are different scopes.

Follow these steps

Create the second location with its own slug and title, for example course-print-annex / Annex. Reopen each card and confirm its address/timezone/equipment remain distinct.

Historical result: course-print-main and course-print-annex are separate Active records, both America/Chicago. This proves two saved locations, not automatic filtering of every application page.

For a concrete stock example, open Storefront → Inventory, select the SKU and create/select its inventory row at the intended saved location. Compare the module's All Locations filter with each named location. A location record does not automatically assign inventory, staff, service points or devices. Use those modules' explicit location fields. Where an operational application exposes a current-location selector, test that consumer separately; do not assume Appmint has BusinessMade's selector on every screen.

Check the result: Two locations retain separate settings and the operational scope follows the selected branch.

Troubleshooting and recovery

Read the actual error and inspect persisted state before retrying a create or other write. Keep the selected organization, record and operation visible. A saved configuration, permission, provider connection and working consumer are separate checks; verify the one the lesson claims. Reopen after saving and compare a controlled alternate/failure path where the chapter calls for it.

Next steps

You can now follow the module’s setup and check its result. Use the relevant chapter for an alternative, and verify the actual consumer before treating configuration as complete.

Limitations and checks

Current modern BusinessLocations editor inspected. This is not an instruction to choose a tax rate without business context; demonstrate the configured value. Physical output, transactions and geofence checks remain live verification. No location or printer configuration changed during script writing.

What this feature does

Data Transfers lets one organization propose a copy and an administrator at the receiving organization decide whether to accept it. Creating a request does not place the records in the other organization. Acceptance starts a background job; its results and the destination records must both be checked.

Use this when you deliberately need selected Appmint records in another organization. It is different from exporting a CSV or moving stock between business locations. Before starting, agree the source, receiving organization ID, records and intended purpose with the receiver. Use two controlled organizations and a small selection for your first rehearsal.

The current transfer builder creates Copy requests. It has no Copy/Move selector. Existing request details can describe Move, but this guide does not invent a Move creation control.

1. Open the transfer list and choose records

1. Open Configuration → Data Transfers. Coming to us contains incoming requests; We sent contains your outgoing requests. The waiting badge concerns pending incoming requests.
2. Choose Send collections to another org. The builder replaces the list in the panel. Back returns to the list; a draft is not a sent request.
3. Under What goes, choose Add a collection. Use Find a collection to locate the intended collection and add it. Check its displayed collection name and internal datatype so you do not choose a similarly named type.
4. A newly added line defaults to Entire collection. For the first test, choose Selected rows, or the table button titled Pick rows in the table.
5. Tick the disposable rows you intend to send. Choose Use these N rows. Back in the builder, confirm Selected rows remains active and that the row count matches your selection.
6. Use Add more only for another required collection. Remove takes an unintended collection out of this proposal; it does not delete its source records.

Do not send while a collection is still counting or says count unknown. Review each line, not just the combined total: an unintended Entire collection line can include many more records than your sample. Referenced customers, files, schemas and related records are not guaranteed to accompany a chosen row automatically; inventory these dependencies before transferring linked data.

2. Validate the destination and send a copy request

1. Under Where it goes, enter the receiving Organization id—the identifier used for sign-in, not merely its display name.
2. Wait for the check beside the field. Read Sending to and confirm the returned organization name with the receiver. Correct an unknown or wrong ID before continuing.
3. Enter Reason, such as Copy approved training records, and Note to them, describing the selected records and why the receiver should accept them.
4. Check every included collection and row count one last time. Choose Send now once and wait for the returned result.
5. Inspect the request detail opened after creation, or return to We sent and open the matching request. Confirm its source, target, requester, contents, copy mode and pending state.

A pending request means the receiver has not yet completed the transfer. The builder explains that the receiving ConfigAdmin has seven days to accept. Do not create duplicates merely because destination records are not present while acceptance is pending.

3. Review and accept from the receiving organization

Concept illustration: This builder proposes copies; sending the request does not copy the records yet. Acceptance starts a background job. A partial result needs row-by-row reconciliation. This is not an application screenshot or evidence that the action has run.

1. Sign in to the intended receiving organization with its authorized administrator account. Open Configuration → Data Transfers → Coming to us.
2. Open the request from the agreed source. Compare What is in it, record counts, mode, reason and message with the agreed proposal.
3. Choose Accept. Read the confirmation naming the source and number of records. For a copy, the originals remain in the source. Confirm with Accept and transfer only when this is the intended request.
4. Keep the detail open while it is accepted/running. This view refreshes progress approximately every two seconds while those states apply. Acceptance itself is not completion.
5. Read What happened, including Transferred, Failed and any grouped failure reasons. A nonzero transferred count with failures is a partial result.
6. Open the receiving collection and inspect the copied sample records by their identifying fields. Compare important values and referenced records with the source. Return to the source organization and confirm the originals remain.

This independent destination check is essential: a completed request is transport evidence, while usable destination records establish the result you wanted. Do not assume ID collision handling or relationship remapping without checking your particular records.

4. Decline, withdraw and handle partial results

To refuse an incoming pending request, open it from Coming to us, choose Decline, optionally explain why, then use Decline it. Reopen the request and check the recorded decision.

To cancel your outgoing request while it is pending, open it from We sent, choose Withdraw, read the confirmation and confirm. Reopen the request and verify its withdrawn state. Withdrawal is not an undo for an already accepted transfer.

An existing request marked Move deserves separate review: its detail warns that source records are deleted after they land. The current builder only creates copies. Do not select Accept on a move when you intended to retain the originals.

For failures, record the request ID, affected collection and individual failure reasons. Compare destination records before sending another proposal so successful rows are not duplicated. If loading fails, use the displayed retry action; use Refresh on the request list to reload it. The current list fetches up to 200 incoming and 200 outgoing records, so its loaded rows are not necessarily every historical request.

Limitations and checks

Reviewed current org-transfer/app.tsx, transfer-builder.tsx, request-detail.tsx and sidebar route. Corrected the previous instruction to choose Copy/Move: that selector does not exist in this builder, which submits copy mode explicitly. No request was sent, accepted, declined or withdrawn during this pass.

Real builder, selected-row, destination-validation, pending-request, acceptance/progress and independent destination-result captures remain missing. Two controlled organizations are required to verify the full path, permissions, expiry, conflicting IDs, dependencies and partial failure. This is a documented guide, not a completed live transfer demonstration.

Overview

Appmint Blacklist is a domain-record collection. We will create a clear domain entry, inspect its saved values and distinguish maintaining the list from proving that a particular feature enforces it.

Before you add an entry

Use a disposable hostname such as unwanted.example and record its intended purpose. This is a filtered flexdata gallery (data.application = blacklist), not a list of blocked customer accounts. The standard domain field is displayed as a large code control despite containing a hostname. Enter only the hostname; HTML, https://, URL paths and email addresses are not its expected value.

No matching Blacklist UI capture was found for this pass. The saved collection behavior and any enforcement consumer still need a live check. If you cannot identify the feature that reads this collection, use the course for record maintenance only; do not tell colleagues the entry blocks signups or email globally.

1. Understand the actual record

Why this matters

This menu opens a data gallery filtered to the blacklist application. The standard schema contains domain, reason and status; it is not the Community blocked-user list.

Follow these steps

Open Configuration → Blacklist. Configuration is an admin-access menu; confirm your role if it is absent. Confirm the gallery is for blacklist records and inspect an existing controlled record if available. Open the create form. Locate domain, reason and status. The current domain control is code-styled and hides its label in the schema, so identify it by its saved field rather than mistaking it for an HTML website editor. Do not put a person’s email address into a field that expects a domain.

Check the result: The learner distinguishes this collection from user blocking and content moderation.

2. Create and read back a domain entry

Why this matters

The domain field validates a domain-like hostname rather than an arbitrary URL. A reason explains the decision to other administrators.

Follow these steps

Enter a controlled example such as unwanted.example without https://, a path or an email local part. Enter a specific reason and the status your consuming implementation expects. The inspected schema exposes status as free text and defines no enum; do not invent Active/Blocked choices or enforcement meanings. Save, reopen the record and inspect domain, reason and status. If validation fails, remove URL syntax and check the hostname rather than repeatedly submitting the same invalid value.

Check the result: The domain record persists with an intelligible reason and deliberate status value.

3. Prove enforcement at the consumer

Concept illustration: The domain collection and a feature enforcing it are separate concerns. Do not present a stored hostname as proof of email, login or website enforcement. This is not an application screenshot or evidence that the action has run.

Why this matters

An entry in a list does not automatically prove every signup, message or integration uses it. Enforcement belongs to the feature that reads this collection.

Follow these steps

Identify the actual consuming feature and its supported status semantics from its implementation before enabling a production rule. In a controlled environment attempt the same operation with an allowed domain and the listed domain. Compare the actual responses and resulting records. If both succeed, document that enforcement was not established; do not describe the blacklist as universally blocking the platform. If the operation is rejected, remove or change only the controlled rule and repeat to establish that this record caused the behavior.

Check the result: The effect is attributed to a verified consumer, or clearly marked unverified.

4. Maintain the collection

Why this matters

Corrections need a saved-state check just like creation. Removing a record and a downstream cache updating can be separate events.

Follow these steps

Find the controlled entry in the gallery, open it and correct its reason or intended status. Save and reopen. Check for duplicate entries before creating another spelling of the same domain. Remove only a disposable entry through the gallery’s delete flow and confirm it is gone after refresh. Repeat the controlled consumer check when enforcement is in scope, retaining any cache/delay observation instead of claiming immediate reversal.

Check the result: The collection and any demonstrated enforcement outcome are checked independently.

Troubleshooting and recovery

Keep the exact record and operation visible when reading an error. Inspect persisted state before retrying a write; a timeout does not prove nothing happened. Correct the specific cause and verify the resulting record and consumer independently. An enabled feature, successful configuration save or administrative status is not proof of an external delivery, access boundary or money movement. Preserve unsupported behavior rather than simulating success.

Next steps

You can now use the module’s records and controls in context, and check the result at the point where it matters. Return to the relevant chapter for the advanced path and its verification.

Limitations and checks

Sidebar filter and SDK FDBlacklistSchema inspected. No dedicated enforcement consumer was established in this authoring pass. Status semantics, duplicate behavior and runtime enforcement must not be invented. This course explicitly teaches that boundary; it is not a claim of platform-wide anti-abuse blocking.

Written course script · documented draft · Live event verification pending

This Account module currently renders the same Activity Feed component with the title Activity Logs. It is not a separate server-console or infrastructure-log viewer. The complete workflow below is retained here so this course can be followed directly.

What you will learn

Activity Feed helps you inspect recorded events across your organization. We'll find an event, narrow the list and open its details so you can identify what happened, who was involved and which record to check next.

Start with a question you can check: which recorded event relates to a particular item? Keep the item’s name, collection, complete record ID and approximate change time beside you. If you do not know its ID, open the item in its original module first. Activity Feed is useful for inspecting existing evidence; it is not proof that every module records every action.

1. Open the feed and read its scope

Open Account → Logs. The page title is Activity Logs. Wait for the list to finish loading. A failed request displays a retry state instead of a valid empty list; choose its retry action or Refresh after correcting the connection/access problem.

Read the four figures separately:

The total comes from the server. These two counts describe only this page, so zero errors here doesn't mean there are no errors anywhere in the organization.

The list requests 50 records per page. Use Next and Previous when pagination appears. A recent event missing from the current page may require a search or a different page; do not equate one visible page with all retained activity.

2. Search and combine filters

Enter an identifying term in Search activity… and press Enter. Typing alone does not run the current search handler. Inspect the returned entries.

Use All Actions to select a recorded action and All Types to select a datatype. Filter changes reset the page to 1 and reload. Read the remaining search text as well: it is combined with these filters.

The current dropdown choices are derived from values in the loaded page, not from a complete organization-wide catalogue of all possible actions and datatypes. If the value you need is absent, clear the filters, inspect another page or use a known search term. Do not teach the menu as an exhaustive audit-event taxonomy.

Pressing Enter starts a keyword search from page 1. Restore All Actions and All Types if those constraints exclude the event.

3. Read an event and open its detail

Select the matching event card. The Activity Detail drawer opens.

Use the fields actually present:

1. Read Action and Data Type to identify the kind of recorded event.
2. Check Author against the person or process you expected.
3. Read the full Record ID. The list may show only its trailing characters.
4. Check Status and Timestamp, taking the displayed local time into account.
5. Inspect IP Address and User Agent only if the event provides them.
6. Expand your review to Full Data to see the complete stored record and any event-specific payload.

The list got us to the right event. Here we can see its full record ID and payload. We'll use that identity to inspect the original item rather than guessing from a similar name.

Fields with no value are omitted. An absent author or IP field is not a claim that an anonymous action occurred; the event may not have stored that information.

Do not show secrets or private customer payloads in a screenshot shared with Support. Use a controlled event with useful but non-sensitive values, and inspect Full Data before capture.

4. Follow the evidence back to the module

Concept illustration: Account Logs uses organization activity, not a server-console stream. Refresh after the action; retain exact evidence when the record and log disagree. This is not an application screenshot or evidence that the action has run.

Keep the event's datatype and complete record ID. Close the drawer and open the module that owns that record. Find and inspect the matching item. Compare its current status and relevant fields with the event.

The current detail drawer displays information; it does not implement a universal “Open source record,” rollback or replay action. Use the module menu to open that original record. An event's success label is not a substitute for checking the business result there.

For example, a recorded change can explain why a request reached its current state, but it is not the request itself. Later changes may have occurred after this event. Use the source record's own history where that module provides one.

5. Refresh, recover and report a useful finding

After a new controlled action, return to the feed and choose Refresh. Keep the search and filter scope visible. The page does not establish a live streaming feed merely by being open.

If an expected event is missing, check in this order: correct organization, current filters, first page/search, source action result and whether that module actually emits this activity type. A failed load needs recovery; a successful empty result needs scope checking.

For a reproducible issue, provide the action time, datatype, record ID, expected event and actual result through Support. Include the error text if a request failed. Share only the relevant redacted event fields, not an unreviewed full payload.

There is no export, edit, delete or undo action in this Activity Feed interface. Do not add those operations to the course because a generic activity table exists elsewhere.

Limitations and checks

Use Activity Feed to narrow a question to a specific recorded event, then check its full identity and the original record. Keep page-level counts and missing event coverage in mind when interpreting the result.

Source reviewed: account/logs.tsx, which renders ActivityFeed with an Activity Logs title, components/activity-feed/app.tsx, its directory and the sidebar entry. Required live proof: known event emission, search on later pages, filter options, detail payload, refresh and source-record comparison. Remaining limitation: filter choices come from the loaded page. The later-page keyword reset is corrected locally and regression-tested.

Written course script · documented draft · Controlled restoration pending

Overview

Prepare

Use a disposable custom-collection record with versioning enabled before deletion, plus a second disposable record for permanent removal. Record IDs and useful field values before the exercise. Keep ordinary business records out of the purge demonstration.

1. Understand which deleted records are retained

Why this matters

Retention depends on the collection's tracking behavior. A collection's explicit versioning setting takes precedence; when that setting is absent, the server falls back to its supported datatype list.

Open the training collection's settings in Database and inspect enableVersioning through its actual control. Save the intended setting before creating/deleting the disposable example. Return to the source module, record the test item's identity and delete it through that module's supported action. Confirm the source record is absent.

Enabling tracking after a record was deleted does not recreate a missing retained copy. Deleting a schema is also distinct from deleting its stored records; use the Database/Data Explorer course for that distinction.

2. Locate and identify the Trash entry

Open Trash in the Studio navigation (the retained screen shows it as a separate sidebar entry). Inspect Name, Type, Deleted by and Deleted. Match the name and source datatype, then the actual record ID where available. Similar display names can belong to different collections or deletions.

Use table pagination to inspect older entries. The current page load starts at 50 records and uses a server total where supplied; one page is not necessarily the entire Trash. Use the table refresh to reload the first page. A Deleted records load failure has a retry action and must not be described as an empty Trash.

The Trash controller explicitly handles paging, refresh, restore and delete. Do not promise server-side keyword/status filtering from a generic table control without testing whether this screen forwards that request.

Historical example: “Tutorial Okonkwo bathroom” belongs to cf_project. The row's eye inspects it, the curved return arrow restores it, and the bin permanently removes the retained copy. Check each icon's tooltip before choosing; Restore and Delete have opposite purposes.

3. Restore and check the consuming application

1. Identify the exact row by its name and source datatype, then choose its Restore action.
2. Wait for the request and visible result. If an error is displayed, inspect it before retrying.
3. Return to the original collection or application, choose Refresh, and find the restored item.
4. Open it and compare its record ID and important values with your pre-deletion record.
5. If a page, dashboard or other consumer uses it, inspect that consumer separately. Restoring stored data does not by itself prove all connected behavior.

These captures show the same project name returning with budget 9000 and stage Build. The older Trash frame still displayed the row immediately after its success notice; do not use that transient frame alone to infer failure. Current source reloads Trash and emits a refresh event for the original datatype. A fresh same-ID check is still needed for this course’s current rehearsal.

The current UI wires row restoration; do not advertise bulk restore merely because its helper accepts an array. The backend recreates stored data directly. Restoration is not a promise to replay every business hook, rebuild every external resource or reverse downstream activity.

4. Diagnose an apparent restore failure

If the request fails, read the error and keep the selected record identity. Check the original collection, current permissions and whether a record with that ID already exists. Do not repeatedly click Restore before inspecting both locations.

Important current behavior

If the original ID already exists in the source datatype, the backend removes the Trash copy and leaves the existing source record rather than overwriting it. Therefore a disappearing Trash row and a success notice do not prove that the retained values replaced the current values. Compare the source record with the retained example before and after any conflict test.

If the schema or linked records are missing, restoring one record does not automatically restore those dependencies. Re-establish the supported schema/dependency through its module and inspect the restored record again. Do not invent a one-click whole-application recovery flow.

5. Permanently remove a retained copy

Choose Delete on the second disposable Trash entry. Read the confirmation naming the record and confirm only that retained copy. Refresh and verify the entry is absent. It can no longer be restored through this retained Trash record.

For the bulk alternative, select only known disposable rows, review the selected identities and use the table Delete action with its current confirmation. The server request receives the selected IDs; check the resulting page and any errors. When removal empties the last page, this view steps back to an available page.

No undo is promised. A partial or failed request needs inspection before retrying. A selected row count alone does not prove which records were removed.

Closing and source status

Source reviewed: components/configuration/trash/app.tsx, shared table row-handler.tsx, and AppEngine history/history.service.ts including tracking selection, trash creation and restoration. Pending live proof: actual tracked deletion, identity-preserving restore, existing-ID conflict behavior, consumer dependencies, pagination and controlled purge.

Limitations and checks

The retained sequence demonstrates the historical restore notice and original collection row. No record was deleted, restored or permanently purged during this manuscript pass. Current pagination/error recovery, same-ID detail readback, schema retention settings, downstream consumers and permanent deletion remain independent checks.

BusinessMade entry: Admin → Settings (/admin/settings).

Organization settings are shared defaults. For branch-specific configuration use Admin → Business locations and verify the location override. A location selected in the header does not turn every organization setting into a branch setting.

Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.

What you will configure

BusinessMade Settings holds organization-wide defaults. It is one saved settings record, not the gateway catalogue or a personal preference screen. We will change a controlled value, verify its consumer and inspect the specialized groups without confusing stored configuration with a working integration.

Choose the scope before changing a default

Use Admin → Settings for an organization default. For one branch’s opening hours or device assignment, open Admin → Business locations, choose that branch and inspect its override instead. For your own name or password, use account/profile controls. This prevents a local requirement from unexpectedly changing every location.

Before editing, note the field’s current value and the consumer you will check afterward. Complete one change at a time: Save → wait → Reload → inspect the value → open the consumer. A saved default phone number, for example, is not a provisioned phone number. Do not enable a sync or security requirement merely to test whether the form saves.

1. Read and save the organization settings

The screen loads base-setting and preserves its identity on save. A load failure must not be treated as a new empty organization configuration.

Open Admin → Settings and wait for the form. If Settings failed to load appears, use Retry; do not create substitute values. Inspect the read-only Setting Name and Org Id. Review System Email, System Phone, Default SMS Number, additional Emails/Phones and Address. Change one controlled value, Save, wait, then Reload and check it. Reload also refreshes contact-helper state.

Check the result: The stored value survives refresh without replacing unrelated settings.

Use only the matching current fields: this historical image identifies base-setting, Org Id and the Save/Reload controls. Its older Email Template/SMS Template fields at the bottom have since been removed from the current settings schema; do not look for them here. Message Templates and connected gateways have their own modules.

For a first controlled change, record the current default, change just that field, Save and wait, then Reload to read it again. If you only wanted to inspect settings, leave values unchanged. A visible field edit is not proof that the saved record changed. Use a verified reload to discard unsaved changes; the current Settings-specific Cancel callback does not itself restore a saved record.

2. Notifications and social synchronization

Notification copies are distinct from message templates and sending providers. Current settings do not choose a gateway or notification template here.

Expand Notification Copy To for Order, Reservation or Event. Inspect Enable, To and Delivery Type and configure a controlled recipient for a prepared test only. Save and verify a real resulting notification through that module. In Social Media Sync add the intended Platform, Account Id, Sync types and Config. Choose only scopes supported by the connected account and verify actual synchronization separately. Do not treat the list of possible sync types as proof that every provider implements them.

Check the result: The intended copy or synchronization result is observed rather than inferred from a saved row.

3. Scheduling and time-off defaults

Named shifts and operating hours give staffing screens reusable definitions. A staffing target is not necessarily a hard capacity limit.

Open Staff Scheduling. Add a Shift time with Id, Name, Start and End in 24-hour HH:mm, unpaid break minutes, Roles and Colour. An end earlier than start represents overnight. Set People needed and optional Sub-divisions with People wanted. Configure Days it runs using weekdays for weekly patterns or cycle-day indices for cycles; inspect each day’s override hours, headcount and Off flag. Set Operating hours, Schedule pattern, Cycle length/start where relevant, Plan ahead by and period movement/start. Save and inspect the staffing consumer. In Time off & leave choose counted units, leave year/fiscal start, working days, Who is HR, approval flow, escalation/digest, job levels and public holidays, then verify a controlled request.

Check the result: Consumers show the intended defaults and requests route according to verified rules.

4. Bank sync and marketplace settings

Organization defaults can be overridden by a connected bank. Marketplace configuration and bank refreshes are not the same task.

In Bank Sync inspect Auto-sync, Pause all syncing, Transaction sync, Balance refresh, Honor bank push and Apply to new banks. Save the intended controlled change and compare the connected bank’s own override before expecting a job. In Stowbo Config inspect Take rate, Minimum payout, Payment gateway, Hold on a cart, Customer app URL and Stowbo site. Change only a configured rehearsal marketplace and test its relevant consumer.

Check the result: A consumer’s effective configuration is understood, and no financial action is implied by editing a field.

5. Security settings and recovery

Organization-level security requirements differ from a person enabling their own second factor. Instant card/employee-ID login also differs from a PIN challenge.

Inspect Passcode Login and Passcode Login Mode, comparing passcode with instant. Use controlled staff accounts to verify the chosen mode. Inspect required 2FA for Users and Customers, available methods, new-device authentication and new-device login alerts. Preserve an administrative recovery path before enabling a requirement. Save, reopen and test a separate controlled account; do not use the sole administrator as the first test. Restore the intended value if the consumer fails and retain the actual error.

Check the result: Effective sign-in behavior follows the verified setting; a saved switch is not proof of enforcement.

Separate storage, inheritance and execution

Record three checkpoints for each settings change: the saved organisation default, the consumer's effective value, and the actual result the lesson intends to demonstrate. For example, a default SMS number must also correspond to an available sending setup; typing a number into Settings does not provision it. A branch scheduling override may deliberately differ from the organisation's default. Inspect that override before “fixing” the global value for every location.

This pass does not change security requirements or send notifications. The security, social-sync and bank-sync branches remain procedures awaiting controlled consumer proof. The older settings screenshots contain removed provider/template fields, so they are not used as screenshots for those current branches.

Troubleshooting and recovery

Read the actual error and inspect persisted state before retrying a create or other write. Keep the selected organization, record and operation visible. A saved configuration, permission, provider connection and working consumer are separate checks; verify the one the lesson claims. Reopen after saving and compare a controlled alternate/failure path where the chapter calls for it. If the consumer does not behave as expected, retain the error and the saved record identity before changing more fields.

Check your result

You can now follow the module’s setup and check its result. Use the relevant chapter for an alternative, and verify the actual consumer before treating configuration as complete.

Limitations and checks

SettingView and installed SDK SettingSchema inspected. Some schema groups depend on dedicated provider/modules and require live consumer tests. No configuration, messages, syncs or security requirements changed here. Current schema explicitly removes gateway/template selection from base settings.

BusinessMade routing and outcome check

The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. Open the module through the route stated at the start, perform the controlled procedure, save, reopen and inspect its actual BusinessMade consumer. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.

BusinessMade entry: Admin → Trash (/admin/trash).

Restore supported deleted records and inspect their original modules. A retained copy cannot reverse a bank payment, print a replacement receipt, reopen a cash drawer or undo a completed external refund.

Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.

Written course script · documented draft · Controlled restoration pending

Overview

Trash contains retained copies of supported deleted records. We'll identify a deleted record, restore it and check it in the module that uses it. We'll also distinguish restoration from permanently deleting the retained copy, and explain why some deletions never appear here.

Prepare

Use a disposable custom-collection record with versioning enabled before deletion, plus a second disposable record for permanent removal. Record IDs and useful field values before the exercise. Keep ordinary business records out of the purge demonstration.

1. Understand which deleted records are retained

Why this matters

Retention depends on the collection's tracking behavior. A collection's explicit versioning setting takes precedence; when that setting is absent, the server falls back to its supported datatype list.

Open the training collection's settings in Database and inspect enableVersioning through its actual control. Save the intended setting before creating/deleting the disposable example. Return to the source module, record the test item's identity and delete it through that module's supported action. Confirm the source record is absent.

Enabling tracking after a record was deleted does not recreate a missing retained copy. Deleting a schema is also distinct from deleting its stored records; use the Database/Data Explorer course for that distinction.

2. Locate and identify the Trash entry

Open Admin → Trash. Inspect Name, Type, Deleted by and Deleted. Match the name and source datatype, then the actual record ID where available. Similar display names can belong to different collections or deletions.

Historical BusinessMade entry capture. Its older column labels include Source datatype and History date; current source labels these Type and Deleted and resolves readable collection titles. The pictured user is evidence of the list layout, not an instruction to restore that account. No restore or permanent removal was performed for this course pass.

Before choosing an action, distinguish the row's curved Restore arrow from its trash-can Delete action. If the title is ambiguous, inspect the retained data and compare the original identity you recorded. Do not use a matching name alone when two records share that name.

Use table pagination to inspect older entries. The current page load starts at 50 records and uses a server total where supplied; one page is not necessarily the entire Trash. Use the table refresh to reload the first page. A Deleted records load failure has a retry action and must not be described as an empty Trash.

This is the deleted training request. The Type identifies its original collection, and these fields identify who deleted it and when.

The Trash controller explicitly handles paging, refresh, restore and delete. Do not promise server-side keyword/status filtering from a generic table control without testing whether this screen forwards that request.

3. Restore and check the consuming application

Choose the exact row's Restore action. Wait for the result and refreshed list. Current source also notifies open data views to reload; a restored collection triggers a collection-list refresh. Still inspect the original record rather than assuming another open tab already reflects the change. Return to the original collection/module, refresh and open the same record ID. Compare the fields you recorded before deletion. If it belongs to a page, menu or other consumer, open that consumer and verify its behavior separately.

Restore puts the retained record back in its original collection. Now we'll check its identity and content there—the Trash notice alone isn't the complete result.

The current UI wires row restoration; do not advertise bulk restore merely because its helper accepts an array. The backend recreates stored data directly. Restoration is not a promise to replay every business hook, rebuild every external resource or reverse downstream activity.

4. Diagnose an apparent restore failure

If the request fails, read the error and keep the selected record identity. Check the original collection, current permissions and whether a record with that ID already exists. Do not repeatedly click Restore before inspecting both locations.

Important current behavior

If the original ID already exists in the source datatype, the backend removes the Trash copy and leaves the existing source record rather than overwriting it. Therefore a disappearing Trash row and a success notice do not prove that the retained values replaced the current values. Compare the source record with the retained example before and after any conflict test.

If the schema or linked records are missing, restoring one record does not automatically restore those dependencies. Re-establish the supported schema/dependency through its module and inspect the restored record again. Do not invent a one-click whole-application recovery flow.

5. Permanently remove a retained copy

Choose Delete on the second disposable Trash entry. Read the confirmation naming the record and confirm only that retained copy. Refresh and verify the entry is absent. It can no longer be restored through this retained Trash record.

For the bulk alternative, select only known disposable rows, review the selected identities and use the table Delete action with its current confirmation. The server request receives the selected IDs; check the resulting page and any errors. When removal empties the last page, this view steps back to an available page.

Delete here permanently removes the retained copy. It is not the Restore action, and it is not a command to find and erase every related record elsewhere.

No undo is promised. A partial or failed request needs inspection before retrying. A selected row count alone does not prove which records were removed.

Closing and source status

Recovery depends on knowing what was retained and where it belongs. Identify the original collection and record, restore once, then verify the result in the application. Keep permanent removal for retained copies you deliberately no longer need.

Source reviewed: components/configuration/trash/app.tsx, shared table row-handler.tsx, and AppEngine history/history.service.ts including tracking selection, trash creation and restoration. Pending live proof: actual tracked deletion, identity-preserving restore, existing-ID conflict behavior, consumer dependencies, pagination and controlled purge.

BusinessMade routing and outcome check

The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. Open the module through the route stated at the start, perform the controlled procedure, save, reopen and inspect its actual BusinessMade consumer. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.

BusinessMade entry: Account → Logs (/account/logs).

BusinessMade mounts the shared Activity Logs view. It reads recorded organization events; it is not a POS receipt archive, terminal console or complete financial audit ledger.

Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.

Written course script · documented draft · Live event verification pending

This Account module currently renders the same Activity Feed component with the title Activity Logs. It is not a separate server-console or infrastructure-log viewer. The complete workflow below is retained here so this course can be followed directly.

Understand the records and results

Explanatory diagram, not an application screenshot. A log event and a current record answer different questions; retain both when reporting a mismatch. It explains the distinctions used in the steps below; it does not establish a completed live workflow.

Overview

Why this matters

Activity Feed helps you inspect recorded events across your organization. We'll find an event, narrow the list and open its details so you can identify what happened, who was involved and which record to check next.

Prepare one known recent action whose module actually writes an activity record. Record its time and source record ID. This provides a recognizable search target; it does not establish coverage for unrelated modules.

Trace the record, not just its friendly label

flowchart LR
 A[Known business action and time] --> B[Logs: search and filters]
 B --> C[Activity Detail: full record ID and datatype]
 C --> D[Open the owning BusinessMade module]
 D --> E[Compare current record with the recorded event]

A branch name or customer's display name can appear on several records. The datatype identifies the kind of item, and the full record ID identifies which item changed. Use those together when checking a reported problem. The activity event is evidence about a moment in time; the business record may have changed again afterward.

Before your first search, choose an action you already know occurred and keep its time and source record ID. This is a better test than searching a broad word and assuming the first result explains the issue. The organization selected for the session must match the record's organization; a branch selector does not automatically turn this shared feed into a branch audit.

1. Open the feed and read its scope

Open Account → Logs. The page title is Activity Logs. Wait for the list to finish loading. A failed request displays a retry state instead of a valid empty list; choose its retry action or Refresh after correcting the connection/access problem.

Read the four figures separately:

Why this matters

The total comes from the server. These two counts describe only this page, so zero errors here doesn't mean there are no errors anywhere in the organization.

The list requests 50 records per page. Use Next and Previous when pagination appears. A recent event missing from the current page may require a search or a different page; do not equate one visible page with all retained activity.

2. Search and combine filters

Enter an identifying term in Search activity… and press Enter. Typing alone does not run the current search handler. Inspect the returned entries.

Use All Actions to select a recorded action and All Types to select a datatype. Filter changes reset the page to 1 and reload. Read the remaining search text as well: it is combined with these filters.

The current dropdown choices are derived from values in the loaded page, not from a complete organization-wide catalogue of all possible actions and datatypes. If the value you need is absent, clear the filters, inspect another page or use a known search term. Do not teach the menu as an exhaustive audit-event taxonomy.

Pressing Enter starts a keyword search from page 1. Restore All Actions and All Types if those constraints exclude the event.

Recover from an unexpectedly empty search

Press Enter in Search activity… and wait for loading to finish; the current local handler starts the query on page 1. If the result is empty, clear All Actions and All Types individually if they exclude your known event. Inspect the source record and whether that module emits an activity entry before concluding that the action was lost.

Earlier versions retained the previous page number. That specific local defect was corrected on 5 October and checked with a regression that verifies a page-3 search resets once without fetching the stale page, while a page-1 search refreshes immediately. A new browser walkthrough remains pending.

3. Read an event and open its detail

Select the matching event card. The Activity Detail drawer opens.

Use the fields actually present:

1. Read Action and Data Type to identify the kind of recorded event.
2. Check Author against the person or process you expected.
3. Read the full Record ID. The list may show only its trailing characters.
4. Check Status and Timestamp, taking the displayed local time into account.
5. Inspect IP Address and User Agent only if the event provides them.
6. Expand your review to Full Data to see the complete stored record and any event-specific payload.

Fields with no value are omitted. An absent author or IP field is not a claim that an anonymous action occurred; the event may not have stored that information.

Do not show secrets or private customer payloads in a course recording. Use a controlled event with useful but non-sensitive values, and inspect Full Data before capture.

4. Follow the evidence back to the module

Keep the event's datatype and complete record ID. Close the drawer and open the module that owns that record. Find and inspect the matching item. Compare its current status and relevant fields with the event.

The current detail drawer displays information; it does not implement a universal “Open source record,” rollback or replay action. Show the actual navigation back to the source module. An event's success label is not a substitute for checking the business result there.

For example, a recorded change can explain why a request reached its current state, but it is not the request itself. Later changes may have occurred after this event. Use the source record's own history where that module provides one.

5. Refresh, recover and report a useful finding

After a new controlled action, return to the feed and choose Refresh. Keep the search and filter scope visible. The page does not establish a live streaming feed merely by being open.

If an expected event is missing, check in this order: correct organization, current filters, first page/search, source action result and whether that module actually emits this activity type. A failed load needs recovery; a successful empty result needs scope checking.

For a reproducible issue, provide the action time, datatype, record ID, expected event and actual result through Support. Include the error text if a request failed. Share only the relevant redacted event fields, not an unreviewed full payload.

There is no export, edit, delete or undo action in this Activity Feed interface. Do not add those operations to the course because a generic activity table exists elsewhere.

Limitations and checks

Why this matters

Use Activity Feed to narrow a question to a specific recorded event, then check its full identity and the original record. Keep page-level counts and missing event coverage in mind when interpreting the result.

Source reviewed: account/logs.tsx, which renders ActivityFeed with an Activity Logs title, components/activity-feed/app.tsx, its directory and the sidebar entry. Required live proof: known event emission, search on later pages, filter options, detail payload, refresh and source-record comparison. Remaining limitation: filter choices come from the loaded page. The later-page keyword reset is corrected locally and regression-tested.

BusinessMade routing and outcome check

The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. Use the feed and record identity to investigate the original change; opening Logs does not create a record to save. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.