Espacios de trabajo y equipos

Un espacio de trabajo es el límite organizacional para la identidad, los datos, los créditos y la facturación. Mantenga experimentos personales en el espacio personal y cree casos y playbooks propiedad de la organización en el contexto del espacio de trabajo.

Los roles son propietario, administrador y miembro. Sus principales capacidades dentro del espacio de trabajo son:

Playbooks y Casos tienen una cuenta propietaria de Usuario o Espacio de trabajo (ownerId), que también paga su uso. El propietario personal tiene todos los derechos; los propietarios y administradores actuales ejercen esos derechos para un Espacio de trabajo. Los demás miembros necesitan permisos explícitos de usuario o Equipo, o visibilidad pública para leer contenido publicado. La membresía por sí sola no concede acceso. Al eliminar un miembro, se revocan sus permisos directos sobre los recursos propiedad de ese Espacio, incluidos los completados y archivados. Si la eliminación dejara algún recurso sin editor explícito, añada primero otro usuario o equipo editor, incluidos los recursos completados o archivados. Se conservan los permisos sobre recursos personales y de otros Espacios. Los permisos de Equipo y administración dependen de la membresía actual. El SSO obligatorio se aplica a los miembros; los usuarios externos con permisos directos usan la autenticación normal de Epismo. El acceso de Equipo entre espacios verifica el SSO del espacio de participación. Los listados usan permisos explícitos y la visibilidad pública admitida; la propiedad por sí sola no incluye un recurso.

Los lectores pueden leer contenido compartido, pero no editar; los borradores requieren edición. Los editores pueden cambiar contenido y permisos, conservar al menos un editor explícito al cambiar permisos, archivar y restaurar. Transferir la cuenta propietaria, cambiar el mantenedor, eliminar Casos definitivamente y archivar versiones históricas requieren derechos de propietario. assignedTo indica responsabilidad sin conceder acceso. Un nuevo responsable o mantenedor debe tener edición y, en recursos del Espacio, pertenecer a ese Espacio. Reasignar conserva los permisos; transferir la propiedad no añade automáticamente al antiguo propietario como editor.

Personas de distintos espacios pueden participar en un mismo equipo compartido. Cada empresa gestiona a sus participantes desde su propio espacio y colabora en los casos y playbooks compartidos con el equipo.

En la configuración, el espacio desde el que se participa se «conecta» a ese equipo. Solo los participantes del equipo que sean propietarios o administradores de su espacio conectado pueden enviar, listar o revocar invitaciones al equipo. El destinatario inicia sesión con el correo de la invitación y elige un espacio existente o crea uno; el remitente no elige el destino. Aceptar conecta el espacio y añade al destinatario, no a todos sus miembros. Aceptar en un espacio ya conectado al equipo devuelve HTTP 409 sin consumir la invitación. Use la gestión de miembros del equipo para añadir participantes en ese espacio. Cada espacio administra sus participantes. Un mismo usuario puede participar desde varios espacios; eliminar su membresía en uno conserva su participación en los demás. Desconectar elimina su conexión y participantes sin afectar las demás. El acceso mediante el equipo requiere que el espacio de participación y el origen del recurso sigan conectados. Los permisos directos a usuarios permanecen. Las invitaciones caducan a los catorce días; reenviar cierra la anterior. La conexión no elimina los requisitos de suscripción del espacio.

Consulte Administración y CI en la CLI para conocer las operaciones y Acceso e identidad para conocer el comportamiento de ACL.

La configuración explícita de creación y los cambios de acceso usan access: { visibility, grants }: visibilidad restricted/public y claves UUID de usuarios o equipos, o correos de usuarios registrados, con valores viewer/editor. Los correos se resuelven a UUID antes de guardar; las respuestas usan UUID. Un correo no registrado o roles en conflicto para el mismo usuario resuelto rechazan toda la operación. Cada cambio reemplaza el objeto completo; conserve los permisos ajenos al cambio e incluya el suyo si desea mantenerlo. Los propietarios conservan la gestión independientemente de los permisos. Los responsables y mantenedores no reciben acceso implícito. Los editores pueden consultar y reemplazar permisos, conservar al menos un editor explícito al cambiar permisos, archivar y restaurar. El JSON normal omite mapas privados; los editores pueden obtenerlos con access-get. Consulte Acceso e identidad.

Preparar un equipo con el cliente

Su personal y los participantes del cliente pueden trabajar en un equipo sin dejar sus respectivos espacios. Por ejemplo, ambas empresas participan en «Implementación del cliente A» para utilizar los casos y playbooks compartidos con ese equipo. Cada empresa gestiona a sus participantes y los demás casos y playbooks conservan sus permisos.

Para empezar, un propietario o administrador crea el equipo en su espacio y añade a sus participantes. El cliente también puede crear primero el equipo e invitar a su contacto.

Elija uno de estos dos modelos:

Participar desde espacios separados

1. Un participante del equipo que sea propietario o administrador del espacio remitente envía la invitación al contacto del cliente.
2. El destinatario inicia sesión con el correo invitado y selecciona su espacio o crea uno. El remitente no elige el espacio de destino.
3. El destinatario se incorpora al equipo compartido desde su propio espacio. Este paso conecta ese espacio al equipo y añade únicamente al destinatario. El espacio del cliente añade a los demás mediante la gestión de miembros del equipo. Si el espacio ya está conectado, añada participantes allí en lugar de aceptar otra invitación.
4. Comparta los casos y playbooks previstos con el equipo y compruebe el acceso con un participante del cliente en su espacio seleccionado.

Invitar al cliente a su espacio

1. Un propietario o administrador invita a los miembros por correo. Los usuarios existentes se incorporan inmediatamente; quienes aún no tienen cuenta reciben una invitación y se incorporan al crearla con ese correo.
2. Añada a los miembros incorporados al equipo del cliente. Pertenecer al espacio no concede participación en el equipo ni acceso a casos y playbooks.
3. Comparta con el equipo solo los recursos previstos. Antes de añadir participantes, revise los recursos ya compartidos.
4. Confirme que el cliente puede abrir el caso y el playbook publicado; compruebe edición cuando la necesite. Se aplican los requisitos de pertenencia, suscripción y SSO de su espacio.

Elijan por separado el espacio propietario y de facturación de cada caso y playbook. Crear el equipo no determina la propiedad de los recursos y conectar espacios no la transfiere. Para el acceso por equipo deben estar conectados tanto el espacio propietario como el de participación.

En ambos modelos, conceda editor al equipo si sus participantes deben contribuir o viewer si solo deben leer; conserve un editor interno. El permiso del equipo se aplica a sus participantes: use equipos internos y de cliente separados cuando sus funciones difieran. Compruebe por separado casos, playbooks y copias. Al terminar, revise participantes, conexiones y permisos directos: desconectar un espacio elimina su acceso por equipo, pero mantiene los permisos directos de usuario.

Consulte Trabajar con clientes para el proceso completo y Administración y CI para las operaciones de invitaciones y miembros.

Propiedad, responsabilidad y ciclo de vida

Antes de eliminar un miembro, un propietario o administrador puede previsualizar y ejecutar el traspaso de Casos, mantenimiento de Playbooks y permisos. Las aprobaciones abiertas se transfieren solo si se solicita; las completadas y la autoría permanecen como historial. Elija un sucesor actual y revise la vista previa. workspace member handover <workspace-id> --member-id <user-id> --successor-id <user-id> previsualiza por defecto; use --preview=false para ejecutar y conceder edición explícita al sucesor. Elimine la membresía por separado con workspace member delete --workspace-id <workspace-id> <user-id> y repita el traspaso con --preview=false --finalize para limpiar cambios intermedios. La opción --finalize exige que la membresía ya esté eliminada; no elimina al miembro. La eliminación revoca la autoridad correspondiente del Equipo y de administración del Espacio. El traspaso inicial conserva los permisos directos; la eliminación los revoca sobre los recursos de ese Espacio y la finalización repite la limpieza de permisos añadidos entretanto. Se conservan los permisos personales y de otros Espacios.