# The Imported Service Was a Black Box. Now It Has a Front Door. > When you provision a service through ZopDay, you get its whole story: configuration, live status, and how to reach it. When you Source: https://zop.dev/resources/blogs/zopday-imported-helm-services-settings-overview Published: 2026-07-14 · Author: riya-mittal · Tags: zopday, platform-engineering, helm, kubernetes, developer-experience --- When you provision a service through ZopDay, you get its whole story: configuration, live status, and how to reach it. When you import one from an existing Helm chart, you used to get a box on the canvas and little else. No configuration view, no release detail, and a project made entirely of imported services looked idle even while it served production traffic. That asymmetry is backwards. An imported service is still a real, running workload. It deserves the same visibility as one provisioned from scratch, because the questions you ask of it are identical: what is it configured to do, is it healthy, and how do I reach it. ZopDay now gives services imported from a ZopDev Helm chart their own Settings and Overview, and makes them stand out on the canvas and in project navigation. ## Settings: the chart's configuration, in the open An imported service is defined by its Helm values, but raw `values.yaml` is not a place to reason about a running system. Settings lays the chart's configuration out in clear, grouped tabs, so the knobs that matter are organized instead of buried in indentation. You can see how the service is set up without cloning a repo or spelunking a release. ## Overview: how to reach it, and its live release The Overview answers the two questions you actually have in front of an imported service. First, how do I reach it inside the cluster. Second, what is [actually running](https://zop.dev/resources/blogs/shadow-cloud-spend-forgotten-dev-accounts) right now: its live release status, the image, the revision, and the replica count, plus where the chart came from. It turns a static node on the canvas into a live readout of the workload behind it. Architecture diagram ## A project of imported services no longer looks idle Imported services [now carry](https://zop.dev/resources/blogs/cross-vpc-datastore-connectivity-psc-cloud-sql) a distinct look on the canvas and in project navigation, so they read as first-class citizens rather than unlabeled boxes. That fixes a quiet failure mode: a project or environment made up entirely of imported services used to appear idle, because nothing about it signalled a live workload. Now it [looks like](https://zop.dev/resources/blogs/automated-cloud-scheduling-non-prod-environments) what it is, a running system you happen to have imported rather than provisioned. | Imported service | Before | Now | |---|---|---| | Configuration | Hidden in the chart | Settings, grouped tabs | | Live release | Not shown | Status, image, revision, replicas | | How to reach it | Figure it out | On the Overview | | On the canvas | Looks idle | Distinct, first-class | ## When it helps most This helps most for teams running a mix of provisioned and imported services, where the imported ones were the [blind spots](https://zop.dev/resources/blogs/gcp-databricks-cost-governance) on an otherwise well-mapped canvas. It brings them up to the same standard, so one project view tells the whole truth. If everything you run was provisioned through ZopDay, you already had this visibility; the change simply closes the gap for the services that came in through a Helm chart. Either way, the rule is the same: a service you can see on the canvas should be a service you can actually read.