Safely manage your Zendesk from the AI assistant you already use, via the Deltastring MCP. Beacon configuration platform
← Back to news

Announcing flexible custom object record permissions for light agents and contributors

Zendesk

Zendesk has introduced granular permission controls for light agents and contributors on custom objects, moving away from hard-coded read-only access to admin-configurable permissions at both object and record levels. Previously, these lower-tier roles could only view custom object records; they now can be granted selective rights to add, edit, and delete records depending on organisational needs. This shift addresses a fundamental constraint that prevented teams from leveraging light agents and contributors in workflows requiring data modification—a limitation that forced many organisations to either grant broader access than necessary or restructure their role hierarchies entirely.

The implications for CX teams are material. Administrators can now align custom object access with actual security policies and operational workflows rather than accepting Zendesk's default posture. A Finance team can empower light agents to manage coupon records for campaigns without exposing pricing or legal contracts; support teams can restrict visibility of sensitive customer data whilst enabling junior staff to update non-sensitive fields. For organisations already running lean on licensing costs by using light agents extensively, this removes a significant friction point—the need to upgrade roles simply to perform legitimate business functions. The question becomes whether this flexibility will shift purchasing behaviour, particularly for teams that previously justified full agent licenses as a workaround to permission limitations.

The change also carries implementation weight. Existing custom objects maintain their current behaviour until an admin explicitly reconfigures them, but new objects default to zero access for light agents and contributors. Marketplace app developers must update their code to respect these new permission options rather than assuming default read access. For larger CX operations with complex custom object ecosystems and multiple third-party integrations, this creates an audit and configuration burden—though one that ultimately grants the control many teams have been requesting.