"Insufficient access rights on object id": cómo resolverlo

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id parece casi idéntico a su primo cross-reference, pero apunta a un problema distinto. Este tiene que ver con el registro que estás tocando directamente: el usuario simplemente no puede escribir en él.

Esta guía explica qué significa el mensaje, cómo distinguirlo de la versión cross-reference y una forma repetible de resolverlo.

Qué significa realmente el error

Cuando un usuario inserta, actualiza o elimina un registro, Salesforce comprueba dos cosas antes de permitir la escritura: los permisos de objeto del usuario (CRUD) y su acceso a nivel de registro (compartición). Si falta cualquiera de los dos para el registro que se está guardando, la operación se rechaza con:

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id: <id>

El <id> es el ID de 15 o 18 caracteres de el registro que intentaste guardar, no uno relacionado. El usuario en ejecución puede verlo, o incluso leerlo, pero no tiene acceso de escritura sobre él.

Traduce el mensaje como: “El usuario que ejecuta esta acción no puede editar (ni eliminar) el registro <id> sobre el que actúa."

"object id” frente a “cross-reference id”: no los confundas

Estos dos errores son hermanos y se mezclan constantemente:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
¿Qué registro bloquea?	El registro que estás guardando	Un registro relacionado al que apunta (búsqueda / maestro-detalle)
Código de error típico	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Lo primero que corregir	Acceso Edit/Delete a este registro	Acceso de lectura al registro relacionado

Si el ID del mensaje es el registro en el que pulsaste Guardar, estás leyendo el artículo correcto. Si es un padre, un propietario o un registro de búsqueda, consulta en su lugar insufficient access rights on cross-reference id.

Paso 0: identifica el registro

Copia el ID del error y ábrelo directamente:

https://yourdomain.my.salesforce.com/<id>

Confirma que es el objeto y el registro que esperabas guardar. Todo lo que sigue apunta al acceso de escritura sobre ese registro.

Las cuatro causas, por orden de probabilidad

1. Falta de permiso de objeto (CRUD)

El perfil o los conjuntos de permisos del usuario carecen de Edit (o Delete) sobre el objeto. Los permisos de objeto son la puerta que se evalúa antes que la compartición: un usuario puede tener acceso total al registro y aun así quedar bloqueado si no se le ha otorgado Edit. Consulta permisos de objeto frente a compartición de registros. Otorga el CRUD necesario mediante un conjunto de permisos.

2. Acceso de solo lectura o sin acceso al registro (compartición)

El usuario tiene Edit de objeto, pero solo acceso de lectura (o ningún acceso) a este registro concreto. Causas habituales:

Un valor predeterminado de toda la organización Privado sin ninguna regla de compartición que alcance al usuario.
El usuario no está por encima del propietario en la jerarquía de funciones.
El registro se comparte como Read Only (regla de compartición, equipo o compartición manual), lo que permite abrirlo pero no guardar.

Confírmalo con el botón Sharing del registro y, a continuación, amplía el acceso de lectura-escritura con una regla de compartición, un equipo o una compartición manual. La diferencia entre lectura y lectura-escritura aquí es exactamente lo que separa “poder abrir” de “poder guardar”.

3. Sin acceso de edición a un padre maestro-detalle

Si el registro es el lado detalle de una relación maestro-detalle, editarlo requiere acceso a su padre. Un usuario que solo puede leer el padre (o que no puede verlo en absoluto) no puede guardar el hijo: Salesforce lo notifica como acceso insuficiente sobre el object id del hijo. Otorga al usuario acceso de lectura-escritura al registro padre.

4. Un registro bloqueado o pendiente de aprobación

Un registro bloqueado por un proceso de aprobación activo, o por un lock de Apex, no puede ser editado por nadie (administradores aparte) hasta que se apruebe, se retire o se desbloquee. Esto produce el mismo error incluso para usuarios que genuinamente tienen acceso de edición. Comprueba el historial de aprobación del registro antes de tocar los permisos.

Causa adicional: automatización en contexto de usuario. Un Flow configurado para ejecutarse “en contexto de usuario” o un Apex declarado with sharing aplican el acceso del usuario en ejecución. Si ese usuario no puede escribir en el registro, la automatización falla con este error aunque un administrador lo haya probado sin problemas. O bien ejecuta la automatización en contexto de sistema, o bien otorga al usuario acceso real (causas 1 a 3).

Una lista de comprobación repetible para la solución

Extrae el <id> del error y ábrelo: confirma qué registro falló.
¿Está el registro en un proceso de aprobación / bloqueado? → resuélvelo primero.
¿Tiene el usuario Edit/Delete de objeto sobre ese objeto? → corrige el perfil o el conjunto de permisos.
¿Tiene el usuario acceso de lectura-escritura al registro (no solo lectura)? → comprueba el botón Sharing; añade una compartición de lectura-escritura.
¿Es un hijo maestro-detalle? → otorga lectura-escritura sobre el padre.
¿Hay una automatización ejecutándose en contexto de usuario? → decide entre el contexto de sistema y otorgar el acceso.

La primera comprobación que falle es tu causa raíz.

Por qué este error es en realidad un problema de rastreo de accesos

Cada una de las causas anteriores responde a la misma pregunta de fondo: ¿tiene realmente este usuario acceso de escritura a este registro y a través de qué mecanismo? Eso es tedioso de responder a mano entre CRUD, propiedad, la jerarquía de funciones y seis mecanismos de compartición, sobre todo cuando lectura frente a lectura-escritura es la diferencia.

AgentForceAccess lo responde en lenguaje claro: pega el usuario y el registro, y rastrea exactamente qué permiso o compartición otorga (o bloquea) el acceso de escritura, para que dejes de adivinar cuál de las causas tienes delante.

Preguntas frecuentes

¿Cuál es la diferencia entre "insufficient access rights on object id" y "on cross-reference id"?

"On object id" tiene que ver con el registro que insertas, actualizas o eliminas directamente: el usuario no tiene acceso de edición/eliminación sobre *ese* registro. "On cross-reference id" tiene que ver con un registro *relacionado* al que se llega a través de un campo de búsqueda o maestro-detalle. La misma familia de error, objetivo opuesto. Si el ID del mensaje es el registro en el que pulsaste Guardar, se trata de la versión object-id.

¿Por qué un administrador puede editar el registro pero un usuario estándar recibe este error?

Los administradores suelen tener "Modify All Data" o "Modify All" sobre el objeto, que eluden los valores predeterminados de toda la organización, las reglas de compartición y la jerarquía de funciones. Al usuario estándar lo bloquean los permisos de objeto o la compartición a nivel de registro. Reproduce siempre la acción iniciando sesión como (o mediante "Login As") el usuario afectado para aislarlo.

El usuario tiene acceso de lectura al registro, ¿por qué sigue dando acceso insuficiente al guardar?

La lectura no basta para escribir. Editar o eliminar requiere el permiso de objeto Edit/Delete *y* acceso de lectura-escritura al registro. Un registro compartido como "Read Only" (mediante una regla de compartición, la jerarquía de funciones o una compartición manual) permite al usuario abrirlo pero no guardar cambios, lo que se manifiesta como acceso insuficiente al actualizar.

¿Puede un registro bloqueado o pendiente de aprobación provocar este error?

Sí. Mientras un registro está bloqueado por un proceso de aprobación activo (o un bloqueo de Apex), incluso los usuarios con acceso de edición no pueden guardar hasta que se apruebe, se retire o se desbloquee. Comprueba si el registro está en un proceso de aprobación antes de perseguir permisos.