Saltar al contenido principal

​
Resumen

El Ownership controla quién puede ver y cambiar un registro. Asignas usuarios como owners o followers de un registro; un Journey Manager solo ve los registros que posee o sigue, y solo los owners los pueden cambiar. Para el modelo mental, consulta Conceptos básicos.
El ownership solo afecta a los usuarios Journey Manager. Un super admin o un Master hace bypass total del ownership — ven y pueden cambiar todos los registros, sin importar de quién sean.
El Ownership aplica a muchos object types — Contacts, Organizations, Orders, Content Instances, Documents, Conversations y más.

​
Dónde encontrarlo

Cada registro tiene una lista de ownership donde agregas o quitas sus owners y followers.

​
Roles

RolAcceso
OwnerAcceso completo — ver, editar y eliminar el registro.
FollowerSolo lectura — el registro aparece en sus listas, pero no lo puede cambiar.

​
Properties

Cada entrada de ownership describe la relación de un usuario con el registro:
PropertyTipoRequeridoDescripción
user_idreferenceSíEl usuario que posee o sigue el registro.
roleenumSíowner o follower.
email / given_name / last_namestringAutoLos datos del usuario, completados y mantenidos en sync automáticamente.

​
Default ownership

Los Templates y Profiles pueden definir un default ownership que heredan los registros nuevos. Cuando se crea un registro, sus owners y followers parten de esos defaults, y el Journey Manager que lo crea se agrega automáticamente como owner.

​
Modos de ownership de Documents

Un Document Template elige cómo obtienen su ownership los documentos:
  • Independent (por defecto) — el ownership de un documento viene del default ownership del template más su creador Journey Manager, y lo editas directamente.
  • Sync with contact — un documento copia el ownership de su Contact padre y se mantiene en sync: no lo puedes editar directamente, y los cambios en el ownership del Contact se propagan a sus documentos.

​
Comportamiento y reglas

  • Los usuarios Journey Manager solo ven sus registros. Las listas de un JM se filtran a los registros que posee o sigue. Un super admin o Master hace bypass y ve todo.
  • Solo los owners cambian un registro. Para un JM, actualizar o eliminar un registro requiere ser owner; los followers son de solo lectura. Los super admins y Masters pueden cambiar cualquier registro.
  • Los creadores quedan como owners. Un Journey Manager que crea un registro se agrega como owner automáticamente.
  • Gana owner. Si un usuario fuera owner y follower a la vez, queda como owner.
  • Los datos del usuario se mantienen en sync. Cuando un usuario actualiza su perfil, sus datos en las entradas de ownership también se actualizan.

​
Seeds

El ownership viaja en el array ownership del registro en un Seed estructural — cada entrada es un user_id y un role: 
"ownership": [
  { "user_id": "695eb58adc6fea533b02a8c2", "role": "owner" },
  { "user_id": "695eb58adc6fea533b02a8c3", "role": "follower" }
]
Los Templates llevan su default_ownership de la misma forma.

​
Gobernanza y permisos

Solo un Journey Manager que sea owner del registro — o un super admin / Master — puede cambiar su ownership.

​
Acceso por API

Operaciones dedicadas agregan y quitan owners y followers en un registro, y los endpoints de índice filtran automáticamente por ownership para los usuarios no-admin. Consulta la API reference.

​
Relacionado

Object types

Qué object types soportan Ownership.

Profiles

Define el default ownership que heredan los registros nuevos.