Written guide
What you will learn
This course covers Appmint CRM Promotions and Subscribers. We will configure the promotion type, prepare its public content and inspect the subscriber records it collects. A promotion is separate from a storefront discount or a paid advertising campaign; we will keep those connections explicit.
01. Distinguish promotions from discounts and ads
A Promotion defines a newsletter, offer, gated-content, waitlist or alert experience. It is different from a storefront discount code and from a paid advertising campaign.
Steps
Open Promotions and inspect Dashboard, Promotions and Subscribers. Choose the relevant type filter and open a saved promotion to inspect its identity and purpose.
Check the result
Dashboard data failure uses missing figures; do not present that as zero subscribers.
02. Create an inactive draft
A promotion’s public destination and terms need review before it is active. The schema-driven form exposes Status; deliberately choose Inactive during draft preparation.
Steps
- Open CRM → Promotions, then choose Create Promotion.
- Enter Name as a unique internal identifier and Title as the wording customers will see. For example, use a collection-preview identifier and a clear “New collection preview” title.
- Choose the promotion Type. Newsletter, Offer, Gated Content, Waitlist and Alert serve different purposes; use the one matching what a subscriber will receive.
- Set Status → Inactive while preparing it. The current ticket-independent Promotion schema uses this status for public subscription eligibility.
- Complete the description and relevant channels, confirmation, notification and date settings. For an offer, reference a discount that already exists. For gated content, provide the intended download destination. Leave irrelevant incentive fields empty.
- Choose Create Promotion and wait. If the form displays a save error, keep the draft open, correct the reason and retry; do not assume a row was created.
- Open the Promotions tab, search the title, then open its three-dot menu → Edit. Compare the saved identifier, title, type and inactive state.
Historical form: Status controls whether the promotion is active. Compare the saved status in your own record before inviting subscribers.
These September 28 captures establish the recorded draft’s save/list/reopen sequence. They do not establish a public subscription or delivered incentive.
Check the result
The form is generated from the Promotion schema. Do not assume the initially active switch represents an approved campaign.
03. Prepare customer participation
The customer-facing promotion is where eligibility and participation must be tested. A saved staff configuration cannot establish a working public experience.
Steps
Open the configured destination in an independent customer session. Inspect the displayed offer and required fields. Complete one controlled participation, then open Subscribers and locate the corresponding record.
Check the result
The exact public component/route and schema eligibility fields require current consumer inspection before a complete demonstration. If no usable destination exists, log that missing implementation; do not claim this chapter verified.
04. Inspect subscribers and lifecycle
Subscribers represents participation. Changing or ending an offer should be checked against the actual customer view and the retained subscriber record.
Steps
Filter Subscribers to the intended promotion and inspect the controlled participant. Return to the promotion, edit the intended terms or inactive/end settings and Save Changes. Reload the public destination and compare its availability, then confirm the earlier participation remains correctly recorded.
Check the result
A promotion status is not proof that a storefront discount was applied. Customer eligibility, notifications and expiry remain explicit live outcome requirements.
05. Subscriber lifecycle and a custom website integration
The promotion's public subscription operation is an AppEngine endpoint. A website must call that operation with the organization and promotion name; simply saving a promotion does not create a subscription form on the site. Email double opt-in creates a pending subscriber before confirmation.
Steps
For a custom website or headless integration, use the configured AppEngine base URL and send POST /crm/promotions/{promotion-name}/subscribe with the orgid header. The JSON body accepts email, phone, name, channel, source, sourceUrl, utmSource, utmMedium, utmCampaign and consentText. Supply the real saved promotion name in the path and at least email or phone. For the controlled email branch, use channel email and an address you can inspect. This is an API integration demonstration, not a claim that the CRM editor exposes a website-publish button.
Inspect the response and open Promotions → Subscribers. Filter to the promotion and compare the contact and status. When requireDoubleOptIn is enabled for email, the service creates pending state and a confirmation token that expires after 24 hours. Open the received confirmation route, which uses GET /crm/promotions/confirm/{token} with the organization context, then refresh the subscriber. Inspect active state and confirmed time separately from notification delivery.
To remove participation through the integration, send POST /crm/promotions/{promotion-name}/unsubscribe with email or phone and an optional reason. Refresh Subscribers and inspect unsubscribed status. Do not delete the subscriber merely to represent an opt-out; the service records that transition. A repeated active subscription returns the existing subscriber. An inactive subscriber can enter the resubscribe branch, including another confirmation when applicable.
Check the result
The public service rejects a promotion unless its saved Status is Active and its start/end dates permit participation. Read back those values before testing a subscription. The form implementation also seeds an unused isActive property; that alone is not evidence that the visible Status control fails to save. A not-active response means the subscription did not succeed: inspect the saved status and promotion window.
An invalid or expired token does not confirm a subscription. Subscribers can be pending, active, unsubscribed, bounced or complained. The dashboard loads a bounded record set, so its displayed totals need comparison with paginated subscriber data before being described as an all-time count.
Your next check
Return to the chapter for the action you need. When you change the configuration, check the matching record, customer view or destination again. A saved setting and a successful external outcome are different observations.
What the recorded example proves
The September 28 example saved and reopened an inactive newsletter promotion. Its dashboard count briefly remained zero; the Promotions list and reopened record supplied the useful check. The current source refreshes the promotion list after save, but this pass did not repeat that interaction live.
Use Subscribers to search by email, phone or name, then narrow by promotion and status. A zero total after saving the promotion is expected when nobody has subscribed. Pending, Active and Unsubscribed describe subscriber lifecycle; they are not interchangeable with the promotion’s own active state.
The captured example does not prove email confirmation, notification dispatch, incentive delivery, redemption or unsubscribe. Each needs its own controlled customer-side result before the course can claim the public journey is verified.
Verification notes
BusinessMade Promotions — supporting guide
Overview
This course covers BusinessMade Storefront Promotions and Subscribers. We will configure the promotion type, prepare its public content and inspect the subscriber records it collects. A promotion is separate from a storefront discount or a paid advertising campaign; we will keep those connections explicit.
BusinessMade entry and scope
Open Storefront → Promotions at /storefront/promotions in BusinessMade. This route mounts the shared Promotions module; the surrounding menus are BusinessMade’s. Use Operations → Contacts for customer details, Operations → Customers & Benefits for group eligibility, Admin → Business locations for branches, and Operations → POS / Order entry for counter sales. Keep the organization and record identity consistent across those screens.
The location selector governs the venue-specific POS, but does not establish that every shared Storefront module filters its data by that selection. Inspect the record’s own location and currency. Payments are under Storefront → Payments, while delivery rules and shipments are under Storefront → Shipping; creating this module’s record is not payment or shipping-provider configuration.
01. Distinguish promotions from discounts and ads
Why this matters
A Promotion defines a newsletter, offer, gated-content, waitlist or alert experience. It is different from a storefront discount code and from a paid advertising campaign.
Follow these steps
Open Promotions and inspect Dashboard, Promotions and Subscribers. Choose the relevant type filter and open a saved promotion to inspect its identity and purpose.
Check the result
Dashboard data failure uses missing figures; do not present that as zero subscribers.
02. Create an inactive draft
Why this matters
A promotion’s public destination and terms need review before it is active. The schema-rendered form exposes Status and the inspected new form starts Active; choose Inactive during preparation.
Follow these steps
- Open Storefront → Promotions, then Create Promotion. Enter a unique Name such as
bm-course-newsletterand a readable Title such asNew collection updates. - Change Status to Inactive. Choose Type → Newsletter for this example and select the intended Channels.
- Decide whether Require email confirmation is needed for the email branch. This affects pending versus confirmed participation; it is not evidence that email delivery is configured.
- Leave Discount Code and Download Url empty for a plain newsletter. For an incentive, first create the actual discount or prepare the intended download, then enter its reference. Those fields do not create the underlying incentive.
- Review Notifications, dates, description and terms. Choose Create Promotion once. Search its saved name in Promotions, reopen it and confirm Inactive before any public integration test.
Historical Appmint capture of the shared form. BusinessMade opens it from Storefront → Promotions, not the CRM menu shown here. Status is Active before preparation; change it to Inactive.
Historical shared-module result: Cedar print collection preview is listed as newsletter/inactive. It proves a saved draft, not a public subscription form or delivered email.
Check the result
The form is generated from the Promotion schema. Use the visible Status field, not an assumed Is Active switch. A successful save notice should be followed by a reopened record check. Current source retains an inline save error if saving fails; correct the stated issue before retrying.
03. Prepare customer participation
Why this matters
The customer-facing promotion is where eligibility and participation must be tested. A saved staff configuration cannot establish a working public experience.
Follow these steps
Open the configured destination in an independent customer session. Inspect the displayed offer and required fields. Complete one controlled participation, then open Subscribers and locate the corresponding record.
Check the result
The exact public component/route and schema eligibility fields require current consumer inspection before a complete demonstration. If no usable destination exists, log that missing implementation; do not claim this chapter verified.
04. Inspect subscribers and lifecycle
Why this matters
Subscribers represents participation. Changing or ending an offer should be checked against the actual customer view and the retained subscriber record.
Follow these steps
Filter Subscribers to the intended promotion and inspect the controlled participant. Return to the promotion, edit the intended terms or inactive/end settings and Save Changes. Reload the public destination and compare its availability, then confirm the earlier participation remains correctly recorded.
Check the result
A promotion status is not proof that a storefront discount was applied. Customer eligibility, notifications and expiry remain explicit live outcome requirements.
Find the participation record
- Open Subscribers after the controlled public test. Search the participant's email, phone or name.
- Set the promotion filter to the same saved promotion and inspect the status filter. Clear an old filter before concluding the record is missing.
- A pending participant still needs confirmation in the double-opt-in email branch. Compare the actual received confirmation and refreshed subscriber status before calling it active.
- If no row exists, inspect the public request result and organization/promotion name. Do not repeatedly submit an address merely to make the dashboard counter change.
Historical shared-module capture with no subscribers. It shows where to search and filter; it is not a successful signup or a BusinessMade customer record.
05. Subscriber lifecycle and a custom website integration
Why this matters
The promotion's public subscription operation is an AppEngine endpoint. A website must call that operation with the organization and promotion name; simply saving a promotion does not create a subscription form on the site. Email double opt-in creates a pending subscriber before confirmation.
Follow these steps
For a custom website or headless integration, use the configured AppEngine base URL and send POST /crm/promotions/{promotion-name}/subscribe with the orgid header. The JSON body accepts email, phone, name, channel, source, sourceUrl, utmSource, utmMedium, utmCampaign and consentText. Supply the real saved promotion name in the path and at least email or phone. For the controlled email branch, use channel email and an address you can inspect. This is an API integration demonstration, not a claim that the CRM editor exposes a website-publish button.
Inspect the response and open Promotions → Subscribers. Filter to the promotion and compare the contact and status. When requireDoubleOptIn is enabled for email, the service creates pending state and a confirmation token that expires after 24 hours. Open the received confirmation route, which uses GET /crm/promotions/confirm/{token} with the organization context, then refresh the subscriber. Inspect active state and confirmed time separately from notification delivery.
To remove participation through the integration, send POST /crm/promotions/{promotion-name}/unsubscribe with email or phone and an optional reason. Refresh Subscribers and inspect unsubscribed status. Do not delete the subscriber merely to represent an opt-out; the service records that transition. A repeated active subscription returns the existing subscriber. An inactive subscriber can enter the resubscribe branch, including another confirmation when applicable.
Check the result
The public service rejects a promotion unless data.status is active and its start/end dates permit participation. The installed SDK schema renders Status, which is the field to set and read back. The component also seeds an isActive value internally, but that alone does not establish a user-facing mismatch: do not replace the visible Status instruction with it. If participation is rejected as inactive, inspect the saved status and dates before retrying; no success is established by the editor notice alone.
An invalid or expired token does not confirm a subscription. Subscribers can be pending, active, unsubscribed, bounced or complained. The dashboard loads a bounded record set, so its displayed totals need comparison with paginated subscriber data before being described as an all-time count.
BusinessMade operational handoff — Connect an offer to an actual subscriber and discount
Why this matters
Promotions connects to the saved customer, product or transaction. Follow that identity through the BusinessMade operation rather than creating a second record to illustrate a result.
Follow these steps
Open Storefront → Promotions and prepare the offer’s identity, dates and confirmation settings. For a discount offer, first create the actual code under Storefront → Discounts, then select/reference it on the promotion. Use the customer-facing integration described in the subscription endpoint chapter to create one controlled subscriber, confirm email where required and inspect Subscribers. Open the delivered destination or incentive independently, then complete a supported redemption and compare the order discount. For a newsletter without a discount, stop at confirmed subscription and delivery rather than promising a price reduction.
Recovery and implementation boundary
The menu places Promotions under Storefront in BusinessMade. It is not the paid ads manager. Check the actual saved Status and dates before public participation; an editor save alone does not prove the consumer integration or delivery.
Limitations and checks
Substantive pending work: The menu places Promotions under Storefront in BusinessMade. It is not the paid ads manager. Check the actual saved Status and dates before public participation; an editor save alone does not prove the consumer integration or delivery. Runtime evidence for the taught handoff remains separate from authored coverage. Do not mark the course production-ready until the intended branch’s saved result, failure recovery and customer/provider outcome have been checked.
Next steps
You can return directly to the chapter for the change you need. Keep the saved record and its operational result together: the same customer, product, location and transaction should remain identifiable through each handoff.