Why Did the Same Ad Account Look Different on Two Pages?

In this team project, I submitted two changes that identified ad accounts by brand, first on the account-management page and then on the finance page.

For one category of ad account, different accounts could share the same upstream name, while the people using them identified them by brand. Improving the account page did not finish the job if finance still displayed the old names.

I extended the change from a page label to brand relationships, shared display logic, finance search and API responses. I used AI to help implement code and tests and delivered the work through team review. This article covers two important corrections: one on the server and another during the transition between old and new versions.

Recognize the same account at both entry points

The account page already had brand-association information. For finance, I needed to add valid brand relationships to the response and apply the same display rule.

The implementation continued to join data by a stable account identifier. Brand names were for display only. The server looked up currently valid brand associations; the front end extracted a shared label function for both pages. Renaming a brand could change the label without connecting its amounts to a different account.

Accounts without a valid brand display as unassigned. Multiple brands appear in a fixed order. Inactive brands or associations are no longer returned as current ownership. Other platforms keep their existing naming and management behavior.

The selected format displays the brand without appending an account number. That has a specific limitation: different brands with identical names can still produce identical labels. I kept this limitation in the handoff notes instead of adding another numbering format without agreement just to make the result look fully resolved.

Search must use the name on the screen

Once finance displays a brand label, search cannot continue recognizing only the old name.

I made finance search use the same display result while preserving the search information required for each platform. Users can find an account with the brand they just saw. Later changes to label formatting do not require an independent fix to search rules elsewhere.

One useful test associated two accounts sharing the same upstream name with different brands, then passed the actual API results into the front-end display and search functions. It checked whether each received the right label and whether searching one brand brought in the other account.

That goes further than passing two handwritten examples into a label function. It can catch relationships connected incorrectly between the API and the page.

Review showed that hiding a value was not enough

This account category had another requirement: certain upstream identity information must not be provided to customers. The first implementation hid it from the page and search, but review found that the API still returned those values.

I extended the correction to server responses and the front-end and back-end data definitions. The relevant identity fields return empty values for this account category; other platforms retain their existing information. Tests check not only the labels but also whether prohibited values remain in the response.

The counterexample raised in review changed the implementation scope. The first display change made the information invisible on screen. The API correction stopped sending it to the customer’s browser. Those are separate outcomes.

A new page can still receive an old response

Another check found a rollout-order issue: a new front end could read a brand list from an older back end that did not yet include the field.

I added front-end compatibility handling that treats missing or null values as an empty list, plus tests using the old response format. The page continues rendering without falling back to upstream identity information that should not be exposed.

This version labels both “the old response omitted the field” and “there is no valid brand association” as unassigned. In retrospect, compatibility kept the page working, but the label did not distinguish missing information from an actual lack of assignment. It therefore cannot, by itself, establish the account’s real assignment state.

That limitation belongs alongside the compatibility result. It did not disappear when the page stopped throwing errors.

Follow the data path during acceptance checks

The final checks followed valid brand relationships through API responses into display and search. Alongside normal cases, they covered inactive associations, ordering of multiple brands, old response formats and unintended changes to other platforms.

Archived acceptance records show passing API integration, front-end unit and cross-layer data checks. The case with two identically named upstream accounts associated with different brands also verified the resulting labels and search behavior.

The concrete delivery consisted of shared label logic, finance brand relationships and response changes, with corresponding search, compatibility and test changes. Later naming adjustments can be checked along that path instead of changing text independently on two pages.

This is a retrospective on a team project. My submissions included AI-assisted implementation and team review. Brands and numbers in the figure are synthetic. Acceptance results come from the historical archive, not a new test of the live product.