Weekly technical recapSalesforce & Marketing Cloud
Week ending 15 August 2026

Week of 9 – 15 August 2026

The boat party,
built end to end.

Registration, the thank-you, six confirmation requests through September, and a fault on the registration page that would have made every registrant invisible to all of it.

Prepared 14 August 2026Work performed by Joseph ChiusanoCenters Health Care
20.0Hours performed
3.0Carried in from 8 Aug
14.0Presented this week
9.0Carried into 22 Aug
01 · At a glance

This week

This week at a glance. The boat party registration flow was built end to end. Someone who registers now receives a thank-you immediately, then a sequence of six confirmation requests through September, and the moment they answer they stop hearing from us — which is the piece that was missing last year, when there was no reliable way to know who was actually coming before the day. A fault on the registration page was found and corrected on the way: registrations were being filed under a status the sequence does not look at, so as built, every person who registered would have been invisible to it — no thank-you, no confirmation request, no headcount. Two newsletters are also reported here — Centers Strong August and the Washington three-in-one — both moved into Marketing Cloud with a dead unsubscribe link corrected before either can reach anyone. Alongside those, the wallet pass link defect was corrected, and a data-entry page was found to be silently discarding submissions. 20.0 hours of work was performed. Total effort presented this week 14.0 hours (cap 14.0), with 9.0 hours carried into the week ending 22 August.
02 · The week, day by day

What was done

Each day below sets out what was built, what was checked against the live account rather than assumed, and where it now stands.

Friday 2026-08-07

Centers Strong August newsletter — brought into Marketing Cloud, with a dead unsubscribe link corrected

2.0 hrs

Reported here rather than last week: this was done on the Friday evening, after last week's recap had already been prepared. It is not counted twice — no hours for it appear in the week ending 8 August.

The newsletter now lives in your accountIt was brought across from the external design tool into Marketing Cloud, which was the step blocking it last week. All sixteen images were rehosted onto your own image server at the same time, so the newsletter no longer depends on the design tool's servers to display — if that account lapses or its links change, the newsletter still renders.
The unsubscribe link did not workAs exported, the unsubscribe link carried a piece of leftover placeholder text instead of a real web address — it would have failed for every recipient. That is both the most damaging fault an email can carry for your sending reputation and a legal requirement. It now uses the same standard unsubscribe as the rest of your mail. This is a known trap with exports from that tool and is worth checking on anything else that comes out of it.
Checked against the live version, not the copy we editedThe newsletter was read back out of the account on 14 August and confirmed: no placeholder text remains, the unsubscribe carries the standard link, and no image still points at the external service.

Status: built and verified in the account. Needs a send date and an audience confirmed.

Friday 2026-08-07

Washington three-in-one August email — brought into Marketing Cloud alongside the newsletter

1.25 hrs

Done in the same sitting as the Centers Strong newsletter, and reported here for the same reason — it followed last week's recap.

The same migration, a second emailBrought across from the external design tool into Marketing Cloud, with ten images rehosted onto your own image server, so this email does not depend on the design tool's servers to display either.
It carried the same dead unsubscribe linkThe identical export fault was present here — leftover placeholder text where a real web address belonged. Corrected the same way, to the standard unsubscribe used by the rest of your mail. Two of two emails out of that tool carried the fault, which is why it is worth checking anything else exported from it.

Status: built in the account. Like the newsletter, it needs a send date and an audience confirmed.

Tuesday 2026-08-11

Boat party — the confirmation sequence designed

1.5 hrs

Design work ahead of the build, and one deliberate departure from what was discussed on the call.

The problem being solvedLast year the difficulty was not getting people to register — it was knowing, before the day, who was actually coming. The sequence is built around getting a yes or a no from every registrant and then leaving them alone.
Six sends, not daily — and whyThe request on the call was to chase daily until each person answers. Daily from 1 to 17 September is seventeen consecutive emails to anyone who has not replied. That volume risks Centers mail being filtered as spam, which would cost you the very people you most need to reach. Six escalating sends over sixteen days, tightening at the end, chases just as hard without that risk. This is the one place the build deliberately differs from what was asked, so it is flagged for you rather than buried.

Status: agreed approach documented and handed to build.

Wednesday 2026-08-12

Boat party — emails, pages and the confirmation sequence built

6.0 hrs

The main build day. Everything below now exists in the account.

Three emails builtA thank-you that goes out the moment someone registers; a confirmation request; and a firmer final-call version. All three carry the event artwork and the full event details, and the two confirmation emails record who opens them.
Answering takes one clickBoth confirmation emails carry a large Yes, I'll be there and a quieter No, I can't attend. Either one writes the answer straight back to the campaign record in Salesforce, and each lands on its own confirmation page so the wording matches the answer just given.
The sequence assembledRegisters → thank-you immediately → then nothing until 1 September → confirmation requests on 1, 4, 8, 11, 14 and 16 September, all at 9:00 AM Eastern, the last three in the firmer wording.
Anyone who answers is released — verifiedThe sequence releases anyone whose campaign status becomes Confirmed or Cancelled. Someone who replies on 2 September receives none of the five later messages. This was read back out of the live sequence and confirmed rather than assumed, because it is the difference between a sequence that chases politely and one that harasses people who have already replied.
A decline page builtPeople who answer no need somewhere sensible to land, and their answer needs recording just as firmly as a yes — a no is what frees the seat.
Deliverable: the confirmation sequence, three emails and the decline page, all built against the live campaign record.

Status: built and validating clean, held in draft — nothing sends until it is deliberately switched on.

Thursday 2026-08-13

Boat party — a registration fault found and corrected; build status documented

3.0 hrs

The registration page was checked against the sequence rather than taken on trust, which is where the fault surfaced.

Registrations were being filed under the wrong statusThe page recorded everyone who registered as RSVP, but the confirmation sequence only picks up people marked RSVP Pending. As built, every person who registered would have been invisible to it — no thank-you, no confirmation request, and no headcount before the day. The page now records the status the sequence reads. Corrected and published.
The liaison question is now mandatoryIt was previously optional, which meant the answer would have been missing for most registrants and the information would have had to be chased by hand afterwards.
Written up in fullA build status document setting out what now exists, where to find each piece in the account, what is switched on and what is not, and the three points needing your decision. Every identifier in it was checked against the live account rather than written from memory.
Deliverable: Boat Party 2026 — Build Status (13 August).

Status: registration page corrected and live; build documented.

Friday 2026-08-14

Boat party — wording corrected across the whole email set

1.0 hr

A wording pass across all the event emails together, rather than fixing one and leaving the others to drift.

Corrections appliedA British spelling corrected to US; the event date written out in full where it had been abbreviated; the start time given its PM so it reads consistently with the finish time; and the full venue address, including the postcode, restored on the two emails that had been missing it.
Applied across the set, not one emailAll the event emails were checked together, so the date, the time and the venue address now read identically wherever a guest sees them. A guest who receives more than one of these should never see two different versions of the same detail.
Each change verified after the factEvery edit was re-read from the live account afterwards and confirmed, and a copy of each email was taken beforehand so any change can be undone in one step.

Status: complete. The wording of the two confirmation emails remains a draft and is yours to change — rewriting the words disturbs none of the mechanism behind them.

Thursday 2026-08-14

Saratoga data-entry page — “five entered, only four on the campaign”

1.0 hr

A report that five handwritten entries were re-keyed but only four reached the campaign. Investigated read-only; nothing was written to your Salesforce.

The submission was accepted, then quietly undoneThe entry was taken, a contact record was created for it, and a Salesforce-side duplicate rule deleted that record one second later — taking the campaign membership with it. The page still showed success to the person keying it in. The membership was never created rather than created and lost.
This is not specific to that pageThe behaviour is on the Salesforce side, so every Centers page that files registrations shares it, including the door check-in pages. One earlier attendee from the Arches event is still sitting at the wrong status because of the same thing.
Where the exposure is worstPrecisely where staff are asked to invent an email address for a handwritten sheet. Two ways a submission disappears silently: a blank email, or an invented one belonging to somebody already in Salesforce. Only a genuinely new address, or an exact match to the existing record, is safe.

Status: root cause identified and documented. The fix is a decision for you — nothing has been changed.

Thursday 2026-08-14

Wallet pass — the faulty vendor hand-off link corrected

2.0 hrs

The one known code defect in the wallet pass, carried since 6 August, and the item flagged then as needing to be fixed before any real event.

The link to the pass provider was malformedCharacters that must be encoded before being sent on — spaces and question marks among them — were being passed through raw, which corrupted the hand-off. Corrected on all three pass-creation pages, which now run identical code.
Errors are no longer swallowedThe provider's reply was previously captured and thrown away, so a failure at their end looked identical to a success. The pages now check the reply before continuing.
Verified without spending anythingBoth live pages were confirmed healthy using checks that issue no pass. No pass was created and no vendor credit was used. A copy of each page was taken beforehand, so any of it can be reverted in one step.

Status: written to the pages and verified. Nothing is armed, and the client-facing position is unchanged.

Thursday – Friday 2026-08-14/15

Build status document rebuilt; boat party emails given their own folder; Centers Strong audience investigated

2.25 hrs

Three smaller pieces that landed after the main build.

Build status document updatedReworked with your edits and extended with a table defining each registration status, so the document explains its own terms. The counts were corrected throughout.
Boat party emails moved to their own folderThey had been sitting alongside fourteen genuine Arches assets. They now live in a dedicated 2026 boat party folder, following the same structure used for the 2025 event. Content was captured before and after each move and confirmed unchanged — subject lines, preheaders and bodies all identical.
Centers Strong: the audience question answeredNothing links the August newsletter to an audience — and no Centers Strong edition ever has, going back through March 2026, August 2025 and earlier. So this is not a gap in the current build: the newsletter has always gone out as an ad-hoc send with the list chosen at the time. The audience is an unmade decision rather than a broken connection.

Status: document and folder move complete. The Centers Strong audience remains open and is yours to choose.

03 · Week summary

The ledger

Hours shown are time worked. The week is presented at the 14.0 cap, with the balance carried into the week ending 22 August.

DateWorkHours
2026-08-07Centers Strong August newsletter brought into Marketing Cloud, images rehosted onto your own server, dead unsubscribe link corrected and verified against the live version (performed after last week's recap was prepared; not counted in that week)2.0
2026-08-07Washington three-in-one August email brought into Marketing Cloud in the same sitting, ten images rehosted, the same dead unsubscribe link corrected (also performed after last week's recap was prepared)1.25
2026-08-11Boat party confirmation sequence designed; daily chasing replaced with six escalating sends for deliverability1.5
2026-08-12Boat party build — three emails, the decline page, and the confirmation sequence assembled and its release-on-answer behaviour verified6.0
2026-08-13Registration page filing every registrant under a status the sequence ignores — found, corrected and published; liaison question made mandatory; build status documented3.0
2026-08-14Wording corrected and made consistent across the whole event email set, each change verified live1.0
2026-08-14Saratoga data-entry page investigated — submissions silently discarded by a Salesforce-side duplicate rule; found to affect every page that files registrations, not just this one1.0
2026-08-14Wallet pass — malformed vendor hand-off link corrected on all three pass-creation pages, provider errors no longer swallowed, verified without issuing a pass or spending credit2.0
2026-08-14/15Build status document rebuilt with a status-definition table; boat party emails moved out of the Arches folder with content verified unchanged; Centers Strong audience investigated — no edition has ever had one linked2.25
Work performed20.0
Carried in from the week ending 8 August3.0
Total owed23.0
Presented this week (cap 14.0)14.0
Carried into the week ending 22 August9.0