A project appears under the wrong client. A feedback request carries the wrong account name. Before rebuilding the database, inspect the exact relation on the original record.
This guide handles a wrong selected client page. If the relation is empty, use the missing-client assignment guide instead.
1. Locate the original record
Open the project or request in its original database. Show the Client relation and open the linked client page. Compare the page’s identity with the project brief or other source that establishes the correct assignment.
A name alone may be ambiguous. Two records can have similar names, and an old client entry may still be searchable. Confirm the actual page rather than assuming the visible label proves the assignment.
2. Distinguish three different causes
| What you find | Likely issue | Next check |
|---|---|---|
| Client B selected on Client A’s project | Wrong related page | Correct this record’s selection |
| Relation targets an obsolete client database | Wrong relation source | Assess property configuration and existing links |
| Correct client on the record, wrong dashboard display | View rule or displayed property mismatch | Inspect dashboard filters and property choice |
Correct only the layer that is wrong. Replacing a shared relation property to fix one mistaken selection can affect far more records than necessary.
3. Correct a mistaken selected page
- Record the current selection and the reason for correction in your normal project notes if history matters.
- Open the Client relation on the affected record.
- Remove the incorrect related page from that property.
- Select the existing correct client page.
- Open that page and verify its identity.
- Confirm that the relation contains only the intended client or clients.
Removing a page from the relation removes that association; it is different from deleting the client’s page. Do not delete a client record as a way to repair a project assignment.
If you cannot identify the correct client, record the uncertainty and assign a clarification action. Choosing a plausible name to make the record look complete creates another error.
4. Check the displays that use the connection
Inspect the old client’s project view and the correct client’s project view. If they filter by the Client relation, verify that their filters select the intended client pages. Confirm the original project remains available in All projects.
If you use a corresponding two-way relation, check the linked project list on both client pages. If you use a rollup based on the corrected relation, inspect its output as well. A one-way relation does not automatically provide a matching client-side property.
Understand the distinction through the relations versus rollups guide. If the link is now correct but a derived value remains unexpected, follow the rollup troubleshooting guide rather than repeatedly changing the client assignment.
5. Find the source of repeated mistakes
If every new project starts with the same wrong client, inspect how those records are created. Check a duplicated project’s existing properties and any default client selection in the template you use. A client-specific starting point may be inappropriate for general intake.
Test with one fictional project. Create it through your normal process, inspect the initial Client value, correct the creation path if necessary, and then create another test record to confirm the result.
If a dashboard is involved, inspect its filters too. Do not assume the page containing a linked view establishes the correct client assignment.
Prevent ambiguous assignments
Give client pages recognizable names and keep useful identifying details available. If each project must belong to exactly one client, consider the relation’s one-page limit after reviewing existing multi-client records. That limit prevents multiple selections; it cannot determine which client is correct.
Keep an assignment review in your regular routine. Empty links and wrong links need different checks, so use the missing-client queue alongside occasional verification of newly created projects.
Common mistakes
- Deleting the wrong client’s page. Repair the association on the affected record.
- Adding the correct client without removing the incorrect one. Check the final set of related pages.
- Rebuilding the relation before checking one selection. Diagnose the scope of the problem first.
- Treating filters as access controls. Review sharing separately if sensitive information was involved.
Frequently asked questions
Does removing a client from a relation delete the client?
No. Removing the related page from that property removes the association. Deleting the client’s page is a different action.
Can a project be linked to more than one client?
A relation can allow multiple pages. If your model requires one client, review existing assignments before applying the one-page limit.
Why is every new project linked to the same wrong client?
Inspect the record-creation process, including duplicated records and template defaults. Test a fictional record before changing real assignments in bulk.
Will correcting the relation fix every dashboard?
Inspect the affected dashboards. Their filters or displayed properties may use a different relation or select the wrong client page.
Does the one-page limit guarantee the right client?
No. It restricts the number of selected pages, not the accuracy of the selected client’s identity.
Want this already built?
This guide shows you how to check and maintain the connections yourself. For a broader client and project workspace, explore Freelancer CRM and compare its structure with your workflow.
Reference: Notion relation and rollup documentation.