>

Improving Suburb / City - Postcode Validation in CRM

Refer to Product Ideas
Himanshu
  • Account name - Royal Agricultural Society of New South Wales
  • Region - APAC
  • Client version (Enterprise) - 25.4
  • Description of the issue
    • The Suburb field (renamed from the City field – EV870_CITY) has accumulated many incorrect, misspelled, and mis‑assigned values over time due to free‑text entry and lack of validation. These values appear in the suggestion drop‑down when users enter suburbs, even when they do not align to the selected postcode.
    • For example, postcode 2000 shows a long list of suburbs that either:
      • Do not belong to that postcode, or
      • Exist as multiple misspelled variations
    • While individual account records can be corrected, the suburb suggestion list itself remains polluted, increasing the likelihood of ongoing data entry errors.
    • This issue is not customer‑specific and represents an enterprise‑wide CRM data quality limitation, particularly for globally used fields without regional validation.
  • What does the client want to do? Why do they want to do this?
    • RASNSW wants to:
      • Clean up incorrect suburb values so they no longer appear in the suggestion list
      • Reduce user error during account creation and updates
      • Improve accuracy and confidence in CRM address data
    • As an enhancement, they would ideally like:
      • Postcode‑based suburb validation, where suburb options are limited based on authoritative data (e.g. Australia Post), similar to other CRMs
      • The goal is not just to correct historical data, but to prevent future data quality issues.
  • Please give a descriptive user story. Often clients want to solve a problem by doing X. If we know the problem, sometimes it can be solved via Y.
    • As a CRM user, I want suburb options to be restricted based on the selected postcode, so that I can enter accurate address data without selecting incorrect or misspelled suburbs.
    • Clients often try to solve this problem by manually cleaning records. However, if the root issue is lack of validation at the field level, the problem is better solved by system‑driven postcode/suburb validation rather than ongoing manual clean‑up.
  • What you've already tried or suggested. Why does this not work?
    • Suggested workaround:
      • Filter Accounts (Event Sales or All Accounts)
      • Group by Postcode and/or Suburb
      • Use Edit All to override incorrect suburb values
    • Why this does not fully work:
      • It requires ongoing manual effort
      • It does not prevent future incorrect entries
      • The suggestion list re‑pollutes over time without validation
      • User error remains possible at point of entry
    • Best‑practice guidance was also provided around:
      • Cleaning up legacy account views
      • Using the Accuracy field to flag data reliability
    • These help with governance but do not address the root cause.
  • Business impact if not resolved
    • Incorrect address data will continue to accumulate
    • Reporting and segmentation accuracy remains impacted
    • Ongoing manual clean‑up effort is required
    • Reduced confidence in CRM data by users and management
  • Attach relevant files (such as screenshots)

    • Post Code field in the database representing different naming convention followed by users

    • Suburbs in database using postcode 2000

       

    • Australian Post Code Website Example for Post Code 2000

  • Links to articles where you've looked for solutions and also other steps you've taken to research the issue.

Comments

2 comments

Date Votes
  • Seth Halvaksz

    Himanshu, thanks for submitting the enhancement request.

    Tagging Carissa Harrison for consideration as part of the Sales AI project.

  • Himanshu

    Thank you.

Please sign in to leave a comment.

Didn't find what you were looking for?

New post