How to Create Admin-Only Columns in a WordPress Table

Updated July 2026 • 6 min read • By Fahad Murtaza

Table-level role access controls who can see a table at all. Column-level role visibility controls which columns within that table are exposed to each role. The two features stack, and the combination is what makes TableCrafter suitable for CRM tables, HR directories, and inventory systems where some columns are genuinely confidential. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV, Excel, JSON, and Save as PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or Gutenberg block.

What Is the Use Case: A CRM Table with Internal Columns?

Imagine a Gravity Forms-backed CRM where each entry holds a company name, contact email, deal stage, assigned rep, internal notes, and an internal lead score. The rep-facing view should show company, email, deal stage, and assigned rep. The Notes and Internal Score columns should be invisible to everyone except administrators. No hints, no blank space, no "hidden" label, simply absent from the DOM.

This is exactly what column role visibility is designed for. The column is not filtered or collapsed, it is not rendered at all for users who lack the required role.

How Do I Open Column Settings?

In the TableCrafter admin, open your table and expand the 2. Select & Configure Fields collapsible section. Each configured column appears as a draggable row with an expand arrow on the right. Click the arrow for the column you want to restrict, in this example, Internal Notes.

Inside the expanded column settings you will find a Visible to roles (Pro) set of checkboxes listing all registered WordPress roles. By default every role is checked, meaning the column is visible to all users who can see the table. Uncheck all roles except Administrator to make the column admin-only.

How Do I Configure the Internal Notes Column?

1. Expand the Internal Notes column row.
2. Locate Visible to Roles.
3. Uncheck Subscriber, Contributor, Author, and Editor. Leave only Administrator checked.
4. Repeat for the Internal Score column.
5. Click Save Table.

Now reload the frontend page as an Editor-role user. The table renders with all columns except Internal Notes and Internal Score. The column headers are absent. The cell content is absent. The HTML output contains no reference to the hidden columns whatsoever.

What the HTML Output Looks Like?

For an administrator, the rendered table header looks like:

<thead>
  <tr>
    <th>Company</th>
    <th>Email</th>
    <th>Deal Stage</th>
    <th>Assigned Rep</th>
    <th>Internal Notes</th>
    <th>Internal Score</th>
  </tr>
</thead>

For an Editor-role user, the exact same shortcode produces:

<thead>
  <tr>
    <th>Company</th>
    <th>Email</th>
    <th>Deal Stage</th>
    <th>Assigned Rep</th>
  </tr>
</thead>

Two different users, same shortcode, same page, completely different column sets delivered by the server.

How Does CSS Fallback for Defense in Depth Work?

TableCrafter's server-side enforcement is the security layer. CSS hiding is not a substitute, a user can disable stylesheets in seconds. That said, adding a CSS fallback is reasonable as a defense-in-depth measure, particularly if you are on a caching setup where a logged-out page cache might briefly serve stale markup to an authenticated user before the cache warms.

TableCrafter adds a data-column attribute to each <th> and <td> element using the column's machine name. You can target specific columns with:

/* Never let internal columns display even if something goes wrong */
[data-column="internal_notes"],
[data-column="internal_score"] {
  display: none !important;
}

Add this to your theme's style.css or a Custom CSS field in the Customizer. It will not affect admins because the server never sends those columns to non-admin users, the CSS rule simply never fires for them. It does mean that if a caching bug ever delivers admin markup to an editor, the columns still will not appear visually.

How Does Export Work with Admin-Only Columns?

If your shortcode includes export="true", the CSV or Excel export respects the same column visibility rules. An Editor downloading the table gets a file with only the four public columns. The Internal Notes and Internal Score columns are absent from the export file, not just hidden in the header row.

[tablecrafter id="1" edit="true" export="true" search="true"]

This means you can safely enable export for all roles without risking internal data leakage through the download.

How Does Multiple Admin-Only Columns at Scale Work?

For tables with many columns, say, a 20-column product catalog, each column's role visibility is configured independently in the 2. Select & Configure Fields section. There is no single table-level toggle that inverts the default; you set the Visible to roles (Pro) checkboxes on each column individually.

The practical workflow for a table where most columns should be admin-only is to start from the top: expand the first column, uncheck all roles except Administrator, collapse it, then move to the next. The same approach works in reverse for tables where most columns are public and only a few are restricted: leave most columns at their default (all roles checked) and only expand the sensitive columns to restrict them.

When you have multiple columns with the same visibility requirements, configure one first and verify it works at the frontend before applying the same settings to the rest. Logged-in administrator users always see all columns regardless of the role settings, so to confirm a non-admin column is actually hidden, verify by switching to an incognito window logged in as an Editor or Subscriber.

The TC_Column_Visibility class handles enforcement server-side, which means the restriction applies identically regardless of which data source the table uses. A column marked visible only to Administrator behaves the same way whether the table connects to Gravity Forms, Google Sheets, or a REST API.

What Are the Next Steps?

With admin-only columns configured, the natural next layer is table-level access control, which determines whether a user can see the table at all rather than which columns they see within it. Open the table builder, expand 3. Table Features, and scroll to the User Permissions group. The Table Access Control multi-select lets you restrict the entire table to specific roles. Combining table-level access with column-level visibility gives you precise control: a manager role can see the full table including salary columns, an employee role sees the same table but without those columns, and a guest sees nothing at all.

The next common concern is how editor and viewer roles interact with inline editing. Column role visibility controls whether a column is visible; a separate setting in the Selection & Editing group controls whether the table has inline editing at all. A column can be visible to a role but still not editable, giving that role read-only access to the data while the same column is editable by a higher-privilege role. The guide on configuring editor vs. viewer roles walks through how the role hierarchy resolves when a user holds multiple roles simultaneously.

Finally, verify your configuration by exporting a test row as an Editor-role user. The exported file should contain only the public columns. If a hidden column appears in the export, there is likely a caching layer serving a stale admin-generated response. Clear your page and object caches and retry.