---
title: "Grupos de aprobación"
description: "Un grupo de aprobación es un conjunto con nombre de miembros del workspace, junto con el número de firmas que se requieren de ellos antes de que una acción sensible surta efecto."
url: https://docs.fystack.io/es/product/approval-group
last_updated: 2026-11-13
---

> ## Documentation index
> Fetch the complete documentation index at: https://docs.fystack.io/llms.txt
> Use it to discover all available pages before exploring further.

# Grupos de aprobación

Un **grupo de aprobación** es un conjunto con nombre de miembros del workspace, junto con el número de firmas que se requieren de ellos antes de que una acción sensible surta efecto.

Cada grupo tiene tres elementos:

- **Miembros**: los usuarios del workspace autorizados a aprobar en nombre de este grupo
- **Umbral**: cuántos de esos miembros deben aprobar antes de que la acción continúe
- **Estado**: si el propio grupo ha sido aprobado y está disponible para usarse

Cada workspace incluye un **Default Approval Group**, creado automáticamente con un umbral de 1. Este grupo revisa la creación de tus demás grupos de aprobación, por lo que ya existe antes de que lo necesites.

_Image: Pestaña Approval Group en User Management que muestra el Default Approval Group con su umbral, estado y miembros_

## Dónde se aplican los grupos de aprobación

Un grupo surte efecto una vez que lo vinculas a algo.

| Vinculado a | Qué controla |
| --- | --- |
| Una billetera | Solo los miembros de este grupo pueden aprobar retiros de la billetera, según el umbral del grupo. |
| Una política | Crear, editar o eliminar la política y sus reglas requiere la aprobación de este grupo antes de que se aplique el cambio. |
| Otro grupo de aprobación | Crear un grupo nuevo es en sí una acción sujeta a aprobación, que revisa un grupo existente. |

> **Note:** Solo el **Owner** del workspace puede crear un grupo de aprobación. Los demás
> roles pueden agregarse como miembros y pueden aprobar solicitudes. Consulta
> [User Management](https://docs.fystack.io/product/user-management.md) para ver qué puede hacer cada rol.

## Cómo crear un grupo de aprobación

### Paso 1: abre la pestaña Approval Group

En la barra lateral izquierda, abre **User Management** y selecciona la pestaña **Approval Group**. Los grupos existentes se muestran con su descripción, umbral, estado y los avatares de sus miembros. Haz clic en **+ Create Approval Group**.

### Paso 2: asigna un nombre al grupo y selecciona los miembros

Completa el **Group Name** y, opcionalmente, una **Description**. Ponle un nombre según la función del grupo, como `Treasury Signers` o `Policy Reviewers`.

En **Members**, busca por nombre o correo electrónico, o filtra por rol. Cada usuario muestra su rol en el workspace junto a su nombre. Haz clic en un usuario para seleccionarlo.

_Image: Modal Create Approval Group con nombre del grupo, descripción, selección de miembros y umbral de aprobación_

### Paso 3: define el umbral de aprobación

Usa el selector para elegir cuántos miembros deben aprobar. El formulario repite tu elección debajo, por ejemplo "Requires 2 of 2 selected member(s) to approve."

> **Note:** El umbral no puede superar el número de miembros seleccionados. Un grupo con
> 2 miembros tiene un umbral máximo de 2. Para exigir 3 firmas, primero agrega
> un tercer miembro.

Haz clic en **Create Group** cuando los miembros y el umbral sean correctos.

### Paso 4: espera a que se apruebe la solicitud de creación

Al crear el grupo se genera una solicitud de aprobación que se envía a un grupo de aprobación existente, normalmente el Default Approval Group. El nuevo grupo aparece en la lista de inmediato, pero su estado permanece en **Pending** hasta que se apruebe esa solicitud.

Los revisores reciben una notificación en cuanto se genera la solicitud.

_Image: Panel de notificaciones que muestra una notificación Approval Group Creation marcada como Delivered_

> **Note:** Sin este control, una sola persona podría crear un grupo formado solo por ella,
> vincularlo a una billetera y aprobar sus propios retiros.

### Paso 5: revisa y aprueba la solicitud

Los revisores abren **Approval** en la barra lateral y seleccionan la pestaña **Approval Group Request**, que muestra un contador cuando hay elementos pendientes. Cada fila indica cuándo se generó la solicitud, quién la generó, qué grupo la revisa, el título, el tipo de aprobación y el estado. Haz clic en **Review**.

_Image: Página Approval con la pestaña Approval Group Request que lista una solicitud approval_group pendiente_

El diálogo muestra quién solicitó el cambio, un ID de solicitud que puedes copiar para tus registros y el **Approval Progress** con el estado individual de cada revisor. Agrega un comentario opcional y haz clic en **Approve** o **Reject**. Los comentarios tienen un límite de 500 caracteres. Úsalos cuando rechaces una solicitud, para que el solicitante sepa qué corregir.

_Image: Diálogo de revisión Approval Group Creation con los detalles de la solicitud, el progreso de aprobación y las acciones Approve o Reject_

Una vez alcanzado el umbral, el estado del grupo cambia a **Approved** y se puede seleccionar en billeteras y políticas.

_Image: Pestaña Approval Group que muestra el nuevo grupo con estado Approved_

## Inspeccionar un grupo

Abre cualquier grupo para ver el total de miembros, el umbral, si el grupo está activo y el estado de aprobación de cada miembro mientras haya una solicitud pendiente. El pie del diálogo repite la regla e indica cuántas firmas faltan todavía.

> **Note:** Los cambios de membresía también están sujetos a aprobación. Agregar un usuario
> a un grupo genera su propia solicitud y requiere aprobación antes de aplicarse,
> por lo que nadie puede agregarse discretamente a un grupo que protege una billetera.

_Image: Diálogo Approval Group Detail con los miembros, el umbral, el estado activo y el estado pendiente de cada miembro_

## Estados de los grupos de aprobación

| Estado | Significado |
| --- | --- |
| Pending | El grupo fue propuesto y está esperando las firmas del grupo revisor. Todavía no puede asignarse a una billetera ni a una política. |
| Approved | El grupo alcanzó el umbral de su grupo revisor y está disponible para usarse en todo el workspace. |
| Rejected | Un revisor rechazó la solicitud y esta no surtió efecto. Genera una nueva solicitud para intentarlo de nuevo. |

## Asignar un grupo a una billetera

### Al crear la billetera

En el diálogo **Create Wallet**, expande **Advanced**. El menú desplegable **Approval Group (Optional)** muestra tus grupos aprobados. A partir de entonces, solo los miembros de ese grupo pueden aprobar retiros de esta billetera.

_Image: Diálogo Create Wallet con la sección Advanced expandida, que muestra el menú desplegable Approval Group_

### En una billetera existente

Abre la billetera y luego la pestaña **Settings**. El encabezado de la billetera muestra el umbral vigente.

Dos campos de esta página funcionan junto con el grupo:

1. **Multi-Approval Threshold**: sigue el umbral del grupo asignado. Para cambiar cuántas firmas requiere una billetera, cambia el umbral en el grupo.
2. **Auto-Approval Limit**: los retiros por debajo de este monto en USD omiten la aprobación por completo. Establécelo en 0 para que todos los retiros requieran aprobación.

Cambiar el grupo que usa una billetera también está sujeto a aprobación. La página indica el grupo que hereda la billetera y ofrece una acción **Request Approval**, para que ningún administrador pueda reemplazar por sí solo un grupo estricto por uno permisivo.

_Image: Pestaña Settings de la billetera con Multi-Approval Threshold, Auto-Approval Limit y el campo Approval Group con su aviso de herencia_

## Asignar un grupo a una política

Cada política designa un grupo de aprobación, que decide quién revisa las reglas de esa política antes de que surtan efecto. Consulta [Políticas](https://docs.fystack.io/product/policies.md) para saber qué hacen las políticas y cómo se evalúan las condiciones de las reglas.

### Elige el grupo de gobernanza

En el asistente de políticas, la sección **Governance** contiene el menú desplegable **Approval Group**. Elige el grupo cuyos miembros serán responsables de esta política.

_Image: Asistente de políticas con la sección Governance y el menú desplegable Approval Group_

### Espera la aprobación

Una política recién creada queda en **Pending** con un banner "Awaiting approval", y sus reglas aparecen como pendientes de aprobación. La página de detalle indica el grupo de aprobación responsable.

_Image: Página de detalle de la política con un banner Awaiting approval y el grupo de aprobación responsable_

### Revisa el cambio

Las aprobaciones de políticas muestran **Revision changes**, un desglose campo por campo de lo que se agrega o modifica, incluidos la acción desencadenante, el efecto, la condición y el estado de habilitación de cada regla. Este es el registro de lo que aprobaste.

_Image: Diálogo de revisión Policy Creation con los cambios de revisión, las diferencias de reglas y el progreso de aprobación_

> **Note:** El mismo control se aplica a los cambios posteriores. Editar una regla, agregar
> una regla o eliminar la política genera una nueva solicitud de aprobación, y
> nada surte efecto hasta que el grupo lo apruebe.

## Aprobar un retiro

Cuando una billetera tiene un grupo de aprobación asignado, un retiro de esa billetera entra en la cola de aprobación en lugar de pasar directamente a la firma. Reúne las firmas de los miembros del grupo hasta alcanzar el umbral y luego pasa a la ejecución.

Abre la billetera y selecciona la pestaña **Withdrawals** para ver cada solicitud y su situación. El encabezado muestra el umbral vigente y la cantidad de elementos pendientes. El panel de saldo separa **Available** de **On Hold**, de modo que los fondos comprometidos en retiros pendientes siguen visibles.

_Image: Pestaña Withdrawals de la billetera con retiros pendientes de aprobación, parcialmente aprobados y exitosos, junto con el indicador de umbral y el saldo retenido_

| Estado | Significado |
| --- | --- |
| Pending Approval | La solicitud está en espera y ningún miembro del grupo la ha firmado todavía. |
| You Approved | Tu firma quedó registrada y la solicitud aún no alcanza el umbral. La fila indica cuántas aprobaciones más se necesitan. |
| Success | Se alcanzó el umbral y el retiro se firmó y se transmitió. |

### Seguimiento de quién ha firmado

Abre un retiro pendiente para ver su línea de tiempo de aprobación: el monto, la red y la dirección del destinatario que se están aprobando, y luego cada miembro del grupo con su decisión y el momento en que la tomó.

Cada firma se atribuye a una persona identificada, lo que hace que el registro sea útil cuando necesitas responder a un auditor o rastrear una transferencia inesperada.

_Image: Diálogo Approval Status con el monto del retiro, la red, la dirección del destinatario y una línea de tiempo de aprobación por miembro_

### Qué puede cambiar el flujo

1. El valor del retiro está por debajo del **Auto-Approval Limit** de la billetera, en cuyo caso omite la aprobación multifirma.
2. Una regla de política coincide con un efecto **Allow**, lo que permite que el retiro omita la cola de aprobación.
3. Una regla de política coincide con un efecto **Deny**, lo que bloquea el retiro por completo. Deny siempre prevalece sobre Allow.

Consulta [Retiros](https://docs.fystack.io/product/withdrawal.md) para ver el flujo completo de solicitud y ejecución, y [Políticas](https://docs.fystack.io/product/policies.md) para saber cómo se evalúan las reglas.

## Buenas prácticas

- Asigna a cada billetera de producción un grupo de aprobación con un umbral de al menos 2, para que ninguna cuenta comprometida pueda mover fondos por sí sola
- Haz que el grupo sea más grande que el umbral, por ejemplo 3 miembros con un umbral de 2, para que la ausencia de una persona no paralice las operaciones
- Mantén el **Auto-Approval Limit** en 0 en las billeteras con saldo real, ya que cualquier retiro por debajo de ese monto se firma y se envía sin que una segunda persona lo vea
- Mantén el grupo revisor de las políticas separado de las personas que proponen cambios en ellas, lo que preserva la separación maker-checker descrita en [User Management](https://docs.fystack.io/product/user-management.md)
- Nombra los grupos según su responsabilidad y no según personas concretas, para que el grupo siga funcionando aunque cambie el personal