---
title: "¿Cómo evita que se envíen presupuestos y descuentos antes de que alguien los apruebe?"
blueprint: 004
slug: quote-approval-thresholds
category: Control de procesos
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/quote-approval-thresholds/
language: es
translation_of: https://blueprints.coevera.com/blueprints/quote-approval-thresholds/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# ¿Cómo evita que se envíen presupuestos y descuentos antes de que alguien los apruebe?

**Respuesta corta.** Un **proceso de aprobación sobre la entidad Quote**, disparado al crear o
actualizar y acotado por un **nodo de filtro** normal, que es donde vive el umbral. Un total del
presupuesto con el operador `More` y un valor de `10000` es todo lo que significa «solo por encima
de 10K». El mismo mecanismo funciona con un porcentaje de descuento o un campo de margen.

El control es **`recordLock`**, no una notificación. Dirija la aprobación a **`SalesUnitManager`**
en lugar de a personas con nombre, para que resista los cambios de personal. Y revise
**`expirationResult`** antes de ponerlo en marcha: puede fijarse en *Approve*, lo que significa
que una aprobación que nadie responde se concede automáticamente.

## 01 · El problema de negocio

Los comerciales hacen descuentos para cerrar. La mayoría de las veces eso es exactamente lo que
usted quiere que hagan, y pedir permiso para cada pequeña concesión ralentizaría a todo el equipo
sin ningún beneficio.

El problema está en la cola de la distribución. Unos pocos presupuestos cada trimestre llevan un
descuento o un total que ningún superior habría aceptado, y se descubren a posteriori: al
registrar el pedido, al facturar o cuando alguien ejecuta un informe de márgenes. Para entonces,
el cliente ya tiene la cifra por escrito.

Lo que pidió el negocio:

- los presupuestos que superan un umbral de valor no pueden avanzar hasta que alguien los apruebe;
- todo lo que queda por debajo del umbral no se ve afectado en absoluto: ningún paso adicional,
  ninguna notificación, nada;
- el aprobador es quien gestione en ese momento la unidad de ventas a la que pertenece el
  presupuesto, sin mantener ninguna lista;
- un registro de auditoría que muestre quién aprobó qué y cuándo;
- y que el registro quede realmente retenido, no solo marcado.

## 02 · Por qué falla el enfoque obvio

Se prueban cuatro cosas antes de que alguien recurra a un proceso de aprobación real, y todas
fallan de la misma forma fundamental: *registran una intención* en lugar de *impedir una acción*.

### Un campo obligatorio «aprobado por el responsable»

Autodeclarado y sin control. Quien quiere el descuento es quien marca la casilla, y nada del
registro cambia cuando lo hace. El resultado es un campo que siempre vale `true` y no significa
nada.

### Una automatización que envía un correo al responsable

Es una notificación, no una barrera. En el momento en que sale el correo, el presupuesto ya está
guardado, ya se puede imprimir y ya se puede enviar. Le dice lo que ha pasado; no impide que pase.

### Una etapa del pipeline llamada «Approval»

Una convención, no un control. Las etapas las mueven los usuarios, y un usuario que necesita sacar
un presupuesto la pasará de largo. Además, falsea los datos sin que se note: la etapa dice
«aprobado» porque alguien arrastró una tarjeta.

### Nombrar a los aprobadores uno a uno

Esta sí funciona, hasta la primera reorganización. Los aprobadores con nombre dejan de funcionar
cuando alguien cambia de equipo, se ausenta o deja la empresa, y el modo de fallo es una cola de
aprobaciones esperando a una persona que ya no existe. Además, la lista tiene que mantenerla para
siempre quien recuerde que existe.

> **El requisito real son dos cosas a la vez:** un *bloqueo* del registro mientras la decisión
> está pendiente y un *enrutamiento dinámico* que resuelva el aprobador a partir de la estructura
> de la organización en el momento en que se genera la aprobación. El proceso de aprobación de
> Coevera ofrece ambas cosas; nada más en la plataforma ofrece ninguna de las dos.

## 03 · Configuración: tres llamadas, no una

> **Crear un proceso de aprobación no lo configura, y configurarlo no lo activa.** Son tres
> operaciones distintas, y detenerse después de las dos primeras deja un proceso que parece estar
> ahí y no hace nada.

| Paso | Contiene |
|---|---|
| **1 · Crear** | Solo `name`, `description` y `ownerId`. Ni disparador, ni filtro, ni aprobadores. |
| **2 · Configurar** | Todo el esquema, como una cadena JSON: disparador, filtro, configuración y los nodos de decisión. |
| **3 · Activar** | Una llamada aparte. Hasta que se ejecuta, no se dispara nada. |

### El esquema, por partes

La carga útil de configuración tiene cuatro miembros de primer nivel.

#### trigger

Indica la entidad y el evento y, lo que resulta útil, *quién* puede dispararlo. Además del tipo de
entidad y de un evento como crear o actualizar, el disparador lleva una opción de actor con listas
de unidades y de usuarios. Si se deja en cualquier usuario, se aplica a todos; si se acota,
permite poner una barrera a los presupuestos de un equipo sin tocar los de otro.

#### filter: donde vive el umbral

Es un nodo de filtro normal, la misma estructura que se usa en toda la automatización de la
plataforma. El ejemplo capturado se llama según lo que hace —*sum over 10K*— y contiene una única
regla: el campo de total del presupuesto, el operador `More` y el valor `10000`.

Dos consecuencias que vale la pena destacar. **Por debajo del umbral no se crea ninguna
aprobación**: no es una aprobación que apruebe automáticamente las operaciones pequeñas,
simplemente no se dispara. Y como es un nodo de filtro general, **el umbral puede ser cualquier
cosa por la que se pueda filtrar**: un porcentaje de descuento, un campo de margen, una categoría
de producto o varias condiciones combinadas.

Tenga en cuenta que un valor de filtro numérico sobre un campo monetario se almacena como una
tupla que lleva el importe junto con una referencia a la moneda: en un campo multimoneda, un
número a secas no lo es todo.

#### settings: quién decide y qué queda congelado

| Opción | Qué hace |
|---|---|
| `approvers` | Una lista de entradas, cada una un usuario con nombre o un **tipo de rol**, como el responsable de la unidad de ventas. |
| `allApprove` | Si todos los aprobadores deben estar de acuerdo o basta con uno cualquiera. |
| `canDelegate` | Si un aprobador puede delegar la decisión en otra persona. |
| `recordLock` | **El mecanismo de control.** Determina quién puede editar el registro mientras la decisión está pendiente. |
| `expiration` / `expirationDays` / `expirationResult` | Si una aprobación pendiente vence, al cabo de cuánto tiempo y qué veredicto adopta al vencer. |
| `salesProcessDependency` | Vincula la aprobación a la posición del registro en el proceso de ventas. |

> **Use un tipo de rol para el aprobador, no un id de usuario.** Un aprobador de tipo responsable
> de la unidad de ventas se resuelve a partir de la unidad de ventas a la que está asignado el
> registro cuando se genera la aprobación. Sigue funcionando a través de reorganizaciones, bajas y
> vacaciones, y no necesita mantenimiento a medida que cambia la forma de la empresa. Los
> aprobadores con nombre son el motivo más habitual por el que un proceso de aprobación deja de
> funcionar sin que nadie lo note un año después de construirse.

#### approveNodes y rejectNodes

Dos arrays de nodos de automatización, que se ejecutan según la decisión correspondiente. Son los
mismos tipos de nodo que se usan en la automatización normal, así que todo lo que puede hacer la
automatización lo puede hacer una decisión: el ejemplo capturado usa un nodo de actualización de
registro para mover la etapa del pipeline del presupuesto cuando se concede la aprobación.

Un detalle de forma que pilla desprevenida a la gente: en un nodo de actualización de registro, la
carga útil vive en el `input` de la entidad como una cadena JSON, mientras que el array
`operations` solo indica qué campos de su interior se están escribiendo. Proporcionar operaciones
con un input vacío produce un error genérico que no ayuda.

## 04 · Qué configurar realmente

Para el requisito del §1, la forma es:

| Opción | Valor | Por qué |
|---|---|---|
| Entidad / evento del disparador | Quote · crear o actualizar | Captura tanto un presupuesto creado por encima del umbral como uno editado después hasta alcanzarlo. |
| Actor del disparador | Cualquier usuario | Una gobernanza que exime a algunas personas no es gobernanza. |
| Filtro | Total · `More` · umbral | Por debajo, no se dispara nada. |
| Aprobadores | Responsable de la unidad de ventas (tipo de rol) | Resiste los cambios de personal y de organización sin mantenimiento. |
| `allApprove` | false, para un único aprobador | Solo tiene sentido con más de un aprobador; fíjelo deliberadamente si añade un segundo. |
| `recordLock` | Pueden editar los **Approval Process Managers** | Bloquea a quien lo creó y deja una vía de escalado. Consulte la salvedad del §6. |
| `expirationResult` | **Reject**, no Approve | Consulte el §6: la alternativa concede sin avisar una aprobación que nadie dio. |
| Nodo de aprobación | Mover la etapa del pipeline | Hace visible la decisión en el registro, no solo en el historial de aprobaciones. |
| Nodo de rechazo | Mover la etapa y notificar | La vía de rechazo es la que más a menudo se deja vacía. Consulte el §6. |

Nombrar el filtro según su significado de negocio y no según su mecánica compensa más adelante: el
nombre es lo que ve un administrador cuando intenta averiguar por qué un presupuesto está
bloqueado.

## 05 · Cómo hacer visible la decisión

El historial de aprobaciones registra quién decidió qué y cuándo, y eso satisface la auditoría. No
satisface al equipo de ventas, que necesita ver el estado en el propio registro.

Para eso sirven los nodos de decisión. Al aprobarse, mueva el presupuesto a una etapa que se lea
como aprobada; al rechazarse, muévalo a una que se lea como rechazada y avise al propietario. Si
debe ejecutarse una automatización posterior (publicar un valor, crear una tarea, escribir de
vuelta en un registro principal), el nodo de decisión puede disparar otro proceso en lugar de
intentar hacerlo todo por sí mismo.

Si el Quote es un proxy que sustituye a algo que no puede alojar una aprobación por sí mismo, la
escritura de vuelta es el objetivo mismo del diseño; ese patrón es el del [Blueprint
001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/).

## 06 · Límites y compromisos

### La opción que convierte la gobernanza en teatro

> **`expirationResult` puede fijarse en aprobar.** Con el vencimiento activado y ese veredicto,
> una aprobación que nadie responde se *concede automáticamente* cuando transcurre el plazo.
>
> Esto es peor que no tener ningún proceso de aprobación. Genera un registro de auditoría que
> muestra una aprobación que ninguna persona dio nunca, y lo descubrirá quien haga la auditoría,
> no usted. Si llega a activar el vencimiento, el resultado debe ser rechazar, con el escalado
> gestionado por los nodos de rechazo. Compruebe este valor explícitamente en cada proceso de
> aprobación que herede.

### El bloqueo no es una congelación

El bloqueo del registro tiene dos modos: el registro sigue siendo editable por los **Approval
Process Managers**, o por los **Approval Process Managers** y los aprobadores. Es de solo lectura
para todos los demás, y en ninguno de los dos modos queda congelado. Es sensato, porque deja una
vía de escalado cuando algo urgente está atascado, pero significa que el registro no es inmutable
mientras está pendiente. No lo describa ante un auditor como si lo fuera.

### A qué no se puede asociar una aprobación

Las aprobaciones solo pueden tener como destino **Account, Contact, Lead, Opportunity o Quote**.
Las entidades personalizadas no se admiten como destino de aprobaciones, y el propio registro de
aprobación no admite campos personalizados, así que cualquier metadato de aprobación sobre el que
necesite hacer informes tiene que vivir en el registro de destino. Ambas restricciones, y el
patrón de proxy que las sortea, están en el [Blueprint
001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/).

**Fuente.** Centro de ayuda de Coevera, [Working with Approval
Processes](https://help.coevera.com/en/articles/7327298-working-with-approval-processes): las
aprobaciones «pueden aplicarse a Accounts, Contacts, Leads, Opportunities y Quotes».

### La vía de rechazo suele faltar

En todas las implementaciones que hemos revisado, la rama de aprobación estaba completa y la de
rechazo estaba vacía o incompleta. El fallo es silencioso: un registro rechazado simplemente se
queda donde estaba, sin ninguna señal para su propietario, y parece idéntico a uno que sigue
esperando. Construya los nodos de rechazo al mismo tiempo que los de aprobación, o no los
construirá nunca.

### Otras cosas que conviene saber

- **Creado no significa activado.** Un proceso puede existir, estar completamente configurado,
  informar de que está sano y no dispararse nunca.
- **La configuración es una cadena JSON dentro de la petición**, lo que significa que no se valida
  contra el esquema como los argumentos normales. Se requieren marcadores de tipo en la raíz y en
  los nodos anidados, y una carga útil sin ellos se rechaza con un mensaje que no lo dice.
- **Los valores de filtro monetarios llevan una referencia a la moneda** junto al importe. Un
  umbral sobre un campo multimoneda no es solo un número.
- **Aquí solo se ha verificado una configuración capturada.** El comportamiento con varios
  aprobadores (el orden, la aprobación parcial, lo que hace una delegación con el registro de
  auditoría) debe probarse en su propio espacio antes de confiar en él.

## 07 · Verificación

Un proceso de aprobación es un control. Un control que se cree que funciona y no funciona es el
peor estado posible, así que el plan de pruebas importa aquí más que en la mayoría de las
implementaciones.

- **Confirme que se ejecutaron los tres pasos**: creado, configurado y *activado*. Vuelva a leer
  el estado de activación en lugar de suponer que la llamada tuvo éxito.
- **Pruebe por debajo del umbral.** El comportamiento correcto es que no ocurra nada en absoluto:
  ningún registro de aprobación, ninguna notificación, ningún bloqueo. Una aprobación que se
  dispara y se aprueba automáticamente es otro diseño, y equivocado.
- **Pruebe por encima del umbral** y, por separado, pruebe a *editar un presupuesto hasta que
  supere* el umbral. El evento de crear o actualizar es lo que captura el segundo caso, y es el
  que la gente olvida probar.
- **Verifique el bloqueo como quien crea el presupuesto, no como administrador.** Inicie sesión
  como usuario de ventas e intente la edición. Los administradores a menudo no pueden reproducir
  el bloqueo en absoluto, y por eso se da por bueno cuando no funciona.
- **Ejercite deliberadamente la vía del vencimiento.** Fije un vencimiento corto en un espacio de
  pruebas, deje que transcurra y confirme que el veredicto que adopta es el que pretendía.
- **Ejercite el rechazo, no solo la aprobación.** Confirme que el registro se mueve y que el
  propietario se entera.
- **Confirme que la resolución del aprobador sigue la unidad de ventas del registro.** Asigne un
  presupuesto de prueba a otra unidad de ventas, genere la aprobación y compruebe que se dirige al
  responsable de esa unidad.

**Qué indicaría una regresión:** aprobaciones que aparecen en presupuestos por debajo del umbral;
una aprobación pendiente cuya lista de aprobadores está vacía; registros por encima del umbral que
llegan a un estado cerrado sin ninguna aprobación en su historial; o un historial de aprobaciones
que muestra decisiones fechadas exactamente al cumplirse el intervalo de vencimiento, lo que
significa que decide el plazo y no una persona.

## Blueprints relacionados

- [Blueprint 001 — ¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único
  servicio de
  asistencia?](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/) — por
  qué las aprobaciones no pueden tener como destino una entidad personalizada, y el patrón de
  proxy sobre Quote que lo sortea.
- [Blueprint 007 — ¿Cómo fija precios distintos para un mismo producto por región, segmento o
  contrato?](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) — de
  dónde salen realmente el total y el descuento que comprueba un umbral.
- [Blueprint 015 — ¿Cómo gestiona descuentos por volumen que varían por región y por
  producto?](https://blueprints.coevera.com/es/blueprints/volume-discounts-by-region-and-product/)
  — los descuentos por cantidad y por región que hacen que un presupuesto cruce la línea.

## Preguntas frecuentes

### ¿Cómo se exige aprobación para un presupuesto que supera un determinado importe o descuento?

En Coevera CRM, un proceso de aprobación sobre la entidad Quote incluye un nodo de filtro estándar, de modo que el umbral se expresa como una condición de campo normal: por ejemplo, el total del presupuesto con el operador More y un valor de 10000. Por debajo del umbral no ocurre nada y no se crea ninguna aprobación; por encima, la aprobación se genera automáticamente al crear o actualizar el registro. Como el filtro es un nodo de filtro normal, el mismo mecanismo funciona con un campo de porcentaje de descuento, un campo de margen o una combinación de condiciones.

### ¿Una aprobación del CRM impide realmente que se modifique el registro, o solo avisa a alguien?

Bloquea el registro. La configuración de la aprobación incluye un modo de bloqueo del registro, y ese es el mecanismo de control, no ninguna notificación. Hay dos modos: el registro sigue siendo editable por los Approval Process Managers, o por los Approval Process Managers y los aprobadores, y es de solo lectura para todos los demás. Ninguno de los dos modos es una congelación total, así que el bloqueo es un control sobre el usuario de ventas; conviene saberlo antes de describirlo como inmutable ante un auditor.

### ¿Pueden las aprobaciones dirigirse automáticamente a un responsable en lugar de nombrar aprobadores concretos?

Sí. Una entrada de aprobador puede indicar un tipo de rol en lugar de un id de usuario, por ejemplo el responsable de la unidad de ventas, que se resuelve a partir de la unidad de ventas a la que está asignado el registro en el momento en que se genera la aprobación. Es mucho preferible a nombrar a personas concretas, porque sigue funcionando cuando alguien cambia de equipo, se ausenta o deja la empresa, y no necesita reconfigurarse a medida que cambia la organización.

### ¿Qué ocurre si nadie responde a una aprobación pendiente?

Depende de la configuración del vencimiento, y conviene revisar con atención esa opción: el resultado del vencimiento puede fijarse en aprobar, lo que significa que una aprobación que nadie atiende se concede automáticamente cuando transcurre el plazo. Un control de gobernanza que aprueba sin avisar al vencer el plazo es peor que no tener control, porque genera un registro de auditoría que muestra una aprobación que ninguna persona dio. Fije deliberadamente el resultado del vencimiento.

---

Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.