Looker field not found in view usage_events churn_risk_score: CS dashboard blank

TL;DR

The field name in the explore and the field name in the view have drifted apart, and Looker is refusing to guess. A model refactor, a renamed column in the warehouse, or a view that moved the score into a derived table leaves dashboards pointing at a field path that no longer resolves. Find the fields current home in LookML, update the references or restore a compatible field, validate the model, and the dashboard renders with the same numbers rather than a rebuilt approximation.

Looker field not found in view usage_events churn_risk_score: CS dashboard blank

Use this when

• Looker shows field not found errors naming usageevents and churnrisk_score on CS dashboards
• Other fields from the same view still work on the same dashboard
• A LookML refactor, warehouse column rename, or dbt model change shipped recently

Not for this skill when

• The warehouse table itself lost the column in a source outage, making this a data problem first
• Every Looker explore is down, suggesting a connection or licence problem instead

Steps

1. Reproduce the error in the Looker IDE content validator and in the failing dashboard, and capture the exact field path Looker reports. Then search the whole LookML project for churnriskscore to see every place it is defined, referenced, or was renamed, because a project wide search shows the refactor shape in seconds where file by file reading takes an hour. Verify: all definitions and references to the field are listed from the project search
2. Check the underlying warehouse column. Query the usageevents table or its successor directly and confirm whether churnrisk_score still exists there, was renamed, changed type, or moved into a separate scores table joined elsewhere. Looker can only expose what the model maps, so establish the warehouse truth before editing LookML. Verify: the columns current warehouse name, type, and location are confirmed
3. Repair the LookML at the right layer. If the column was renamed, update the dimension or measure sql and keep the field name stable so dashboards do not break again on the next warehouse rename. If the field moved to a joined view, update the explore join and the field path in the affected dashboards and looks. If a refactor deleted the field by accident, restore it from version control history. Verify: the LookML change is made in a development branch with the field name kept stable for consumers
4. Validate before merging. Run the Looker content validator for the project, open the previously failing dashboard against the development branch, and compare the churn risk numbers on a fixed date range against a direct warehouse query so the restored field is not merely present but correct. Verify: the validator passes and dashboard values match the warehouse query for the test range
5. Merge, deploy the model, and clear any cached results that might keep serving the error or stale values. Then check the dashboards other tiles for the same class of break, because a refactor that moved one field usually moved several and the next tile error is already scheduled. Verify: the production dashboard loads fully and sibling fields from the refactor are verified
6. Prevent the repeat. Add the CS churn dashboard to the list of content the content validator checks in your release process, require LookML changes that rename fields to keep a deprecated alias for one release, and note the field owner in the view file so future refactors notify the dashboard owners first. Verify: the release checklist and alias practice are documented in the project

Why it happens

Looker compiles dashboards against LookML field paths at runtime. When a refactor renames the underlying column mapping, deletes the field, or moves it behind a different join, saved content holding the old path fails with a precise not found error while the data sits safely in the warehouse. The break is a contract break between the modelling layer and its consumers, and it recurs until field names are treated as a published interface.

Compatibility: Looker LookML views, explores, content validation, and underlying warehouse tables, in current Looker versions.

Variants and edge cases

Looker field not found in view error LookML

['The direct phrasing. Project wide search plus the warehouse truth resolves most cases inside one working session.']

churnriskscore missing Looker after refactor

['The refactor variant. Use version control history on the view file to see exactly what the field was before the change instead of reconstructing it from memory.']

Looker dashboard blank field not found CS

['The dashboard variant. Count how many tiles and looks reference the field before fixing, so you can verify you repaired the whole blast radius, not the first tile.']

Edge cases to work through before you close the incident:

• Hidden fields still resolve for some content and not other content depending on access. If only some users see the error, check field access grants and user attributes as well as existence.
• A field can exist but be unusable in an explore because the join to its view was removed. The validator message differs subtly, so read it exactly.
• Renaming the warehouse column back is sometimes faster than a model release. Choose based on how many other consumers use the new name, not on which team shouts first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstO2tGeih0c44bix_0NW2Gw