A concert announcement shouldn't be copied five times

Adding a concert sounds like a small admin task. In practice it meant opening Bandsintown, checking the Virya website, preparing a Facebook post, deciding whether the mailing list should hear about it, reminding the team, and then remembering to do it all again closer to the date.

Each step takes a few minutes, so the work looks harmless. The cost shows up later, when one place has the new date, another has the old venue and the reminder exists only in somebody's head.

One event record#

I made Bandsintown the starting signal, but it doesn't own the whole process. A new or updated event enters one workflow, gets normalised into our own event shape and receives a stable identity. The workflow then decides what actually changed: a new show, a changed time, a new ticket link or a cancellation. An event showing up in the API isn't a reason to announce anything yet.

This matters because synchronisation retries. APIs repeat records, schedules overlap and a provider may return the same event in a slightly different order. Without a stable event key, one concert quickly becomes three posts and two contradictory reminders. So every external action has its own idempotency key and status.

Drafts before publishing#

The next step is preparation. The workflow builds a factual social draft from the city, venue, date and verified ticket link. It prepares an email for the relevant fan segment and can include a Bandsintown follow link, because following the artist there makes future concert discovery easier for both sides. Discord gets a compact preview showing what changed and what needs approval.

I deliberately kept cold social messages out of this flow. Facebook and Instagram permissions are complicated, the APIs don't always allow starting a conversation, and something being technically possible doesn't make it a good idea. A public announcement and an email to somebody who explicitly subscribed are useful. Automatically messaging every profile in the CRM isn't.

Using city data#

City data from CrowdRelay makes the email less stupid too. A show in Wrocław doesn't need to be presented with the same urgency to everyone in Poland. The system can prioritise people who selected the city, showed interest in nearby concerts or asked for reminders. It's still one mailing list, but the message now has some context.

Cancellations and changes#

Cancellations and major changes use the same event identity, so they don't create a second fictional concert. The workflow marks the existing record, prepares the correction and stops scheduled reminders from promoting a show that no longer exists.

Human approval#

There's still a human checkpoint before anything goes public. The workflow is good at copying verified facts into several formats and remembering the next date. A person still needs to notice that the venue asked us to wait until Monday, or that the ticket link points to last year's event.

The result is one clean path:

One concert is now one operational record instead of five loosely related chores, and nobody has to remember the boring follow-ups.