Natural Resources Canada (NRCan) is the federal department responsible for Canada’s natural resources sector: geology, forestry, minerals, energy, the Geological Survey, and the Canadian Forest Service among them. This engagement was part of the federal Government Online initiative of the early 2000s, which set out to put public-facing and internal government services on the web. The Conference Plan system was the internal-tool piece — a web application that let NRCan employees submit conference attendance requests, route them through the approval workflow, register the approved attendees, and generate their conference badges directly from the registration data.
Why FileMaker Pro and PHP both had to be in this build
NRCan, like most federal departments in 2003, ran a lot of its departmental data on FileMaker Pro. FileMaker was the dominant workgroup database of the era, the tool an admin team could stand up without waiting for a central IT project to allocate resources for an Oracle schema. The Conference Plan data lived in FileMaker because that is where the team that owned the workflow already lived. The web interface had to be PHP, because PHP was what the department’s web environment ran on.
That meant the system needed both. FileMaker as the system of record, with the existing schemas the workflow team already used and the existing reports they already ran. PHP as the web layer, with the bilingual rendering, the session handling, the form validation, and the print-template generation. And a bridge between the two that could read and write FileMaker records over the network without forcing the workflow team to migrate their data into a different database.
The bridge
PHP and FileMaker did not talk to each other natively. They spoke different protocols, used different data models, and were designed by teams who had no reason to anticipate each other’s existence. The bridge was the part of the engagement that took the most engineering thought. It needed to translate between FileMaker’s flat-file-with-relationships model and PHP’s relational expectations. The connection lifecycle had to be managed so that a slow FileMaker query did not hang a PHP request. And when the FileMaker server went offline for its overnight backup, the bridge needed to degrade safely so an employee submitting a conference request the next morning did not see a white-screen error left over from the maintenance window. The natural-resource family of projects I was doing for NRCan in that period all needed some version of this bridge, and Conference Plan was the build that exercised the most of it.
End-to-end, not stuck at the form
The brag in this build was that the data flowed all the way through. An employee logged in, submitted a conference attendance request with the cost breakdown and the business justification, routed it to their manager for approval, and once approved, was automatically registered for the conference. The same record then drove the badge generation: name, title, department, conference name, and attendee number, on a print-ready template the admin team could batch-print before the conference. No re-keying. No spreadsheet exports. No “send your details to admin so they can make your badge” emails.
That sounds modest now. In 2003, internal government tools more often than not stopped at the form. A request would land in a queue, get manually entered into a different system for the approval, then re-entered into a third system for the registration, then re-entered into a fourth system for the badging. Each re-keying was a place where details drifted, names got misspelled, and the eventual badge had to be hand-corrected at the conference check-in desk. Conference Plan was deliberately end-to-end so the request and the badge were the same record at different stages of its life.
The bilingual layer
The bilingual concretes for this build were workflow-shaped, not chrome-shaped. An English-speaking manager could approve a French-speaking employee’s request and the employee’s confirmation email arrived in French, on the schedule the employee expected for federal correspondence. The canonical write-up on bilingual-as-infrastructure for federal sector work is in the CTHRB-BCRHT portfolio entry.
- Platform: PHP, FileMaker Pro, custom PHP-to-FileMaker bridge
- The build: Internal end-to-end conference-attendance workflow for NRCan, from employee request through manager approval through registration through auto-generated badge templates, in both official languages
- Client: Natural Resources Canada
- Period: 2003, as part of the federal Government Online initiative
- Family: One of several FileMaker-PHP bridge engagements I did for NRCan in that period
Where this pattern transfers
Federal departments have largely moved off FileMaker since 2003. The underlying pattern — a departmental database the workflow team already owns, talking to a modern web layer through a bridge built to respect both sides — is the same one that shows up now whenever an internal tool needs to integrate with a system the team that owns the workflow is not willing to give up. A Salesforce instance powering a custom web application, an Airtable base feeding a public form, a legacy Microsoft Access database talking to a modern portal: every one of these is a version of the same problem. The technical surface has changed a lot since 2003, but the discipline underneath has not. Building the integration so it serves both ecosystems honestly, rather than forcing one of them to pretend to be the other, is still the part of this kind of work that has to be done by hand on every new engagement.
