Building a Certification Lifecycle Manager That Won't Remind Me Twice

The second completed automation module in Project Daedalus solves a problem that a calendar entry only handles badly: certification renewal is not one date. It includes vendor rules, renewal windows, continuing-education requirements, fees, evidence and a history of what has already been sent.

I wanted the system to answer a more useful question than “when does this expire?” It needed to tell me whether a certification was on track, how much approved continuing education remained, when action became necessary and whether a reminder had already been delivered.

Designing the data before the automation

I started with four related record types: certifications, vendor renewal rules, continuing-education activities and reminder history. Keeping them separate avoided duplicating changing vendor requirements inside every certification record. It also meant CE progress could be calculated from approved activities rather than manually maintained as another number that could drift out of date.

The public repository contains sanitized, storage-independent schemas. The operational records live in a dedicated PostgreSQL service on a private container network. n8n connects with a restricted runtime account that cannot create databases, create roles or act as a superuser. The database is not published on a host port, and its backups are automatically restored into a temporary verification database before they are considered successful.

Making updates safe and usable

A lifecycle system is not useful if maintaining it requires hand-written database commands. I built an authenticated n8n form for adding or updating records, followed by a validation step and an idempotent database upsert. The form deliberately excludes certificate numbers, verification codes, credentials and supporting documents. It stores only the information the workflow needs.

The completed form path validates the submission, writes the renewal rule and certification record, and returns a confirmation page. I tested the path with synthetic data first, then added a real certification record after the workflow behaved correctly.

The duplicate-reminder problem

Sending an email is easy. Proving the workflow will not send the same email every morning is the more interesting part.

Before delivery, the monitor attempts to claim a deterministic reminder record. If that reminder has already been claimed, the database returns no item and the email path stops. A successful send updates the record to sent; a failure records the failed state. That gives the workflow both idempotency and an audit trail instead of relying on execution history alone.

A separate error workflow handles production failures so an outage in the main monitor does not disappear silently. The monitor itself runs on a daily schedule, but only records inside an actionable renewal threshold continue to the reminder path.

Testing the lifecycle, not just the happy path

The validation workflow created synthetic on-track and urgent certifications, added a sample CE activity, calculated remaining credits, exercised reminder claiming, generated the HTML email and confirmed delivery-state recording. I also tested the authenticated record form, production email delivery, database permissions, private network reachability and restore-verified backups.

The last validation step mattered: remove every synthetic certification, rule, activity and reminder, then query the operational database again. That final query confirmed that only the intended real record remained. The validation workflow stays manual-only so test data cannot be recreated on a schedule.

What I learned

The largest lesson was that reliability lives between the visible steps. The form, email and schedule are the obvious parts. The controls that make the system trustworthy are input validation, least privilege, deterministic identifiers, delivery-state tracking, targeted cleanup, failure alerts and a backup that has actually been restored.

DAE-003 is now complete and tested. More importantly, it gave Project Daedalus a reusable pattern for future lifecycle workflows: model the state, restrict access, make repeated execution safe, record outcomes and validate cleanup before calling the module finished.

Explore Project Daedalus on GitHub ↗