Yes. Carbon Fields is registered in code rather than through a UI, but the values still live in standard meta tables. SleekView reads whichever keys you tell it to surface, so the in-code schema stays the source of truth and the admin table simply mirrors what's already in postmeta, termmeta, usermeta, or the options table.

Simple types (text, select, checkbox) edit inline through the meta API. Complex repeaters and associations are best edited in the post screen because their UI is non-trivial, but SleekView shows their summary in the column (a row count for repeaters, the linked title or count for associations) so you can still audit and filter on them.

Both are supported. Build a terms view or users view and surface Carbon Fields keys exactly as you would for posts. The taxonomy view shows term meta as columns next to native term columns; the users view shows usermeta-backed Carbon Fields keys next to user role and last login. The default WordPress admin shows none of this without custom code.

SleekView writes through standard meta APIs, so any carbon_fields_post_meta_container_saved-style hooks on simple keys still fire. The hook payload is the same one Carbon Fields' own save path produces for a single key, which keeps existing custom logic intact for the inline edit cases SleekView handles.

Yes. A built-in filter shows records with empty or missing values for a given key, useful for migration audits and catching content that's about to ship without all its fields populated. Combine it with last-updated filters to find posts that haven't been touched since a schema change but still need their new fields filled in.

Yes. SleekView treats both as plain meta sources, so you can build views that mix Carbon Fields and ACF keys in the same table. This is useful during a migration from one to the other, or on long-running sites where some content models use ACF and others use Carbon Fields, and a single audit view across both is more useful than two separate ones.

Carbon Fields stores values under _carbon_-prefixed keys. SleekView lets you reference either the registered field name or the underlying meta key, so you don't have to remember the prefix when adding a column. The prefix is hidden from the editor view by default, but stays visible to developers who prefer the raw key.

Yes. Per-role view permissions decide which Carbon Fields keys are exposed to a given role. An editor view can show only the public-facing keys (hero copy, featured flag, region) while a developer view shows the full set including internal keys. The role check happens before the query so unauthorized columns are never loaded.