Personalizar la conversión de consultas

Convertir una consulta crea hasta cuatro registros con un solo clic — una cuenta, un contacto, una oportunidad y el rol del contacto en esa oportunidad. Cada campo que arrastra de la consulta hacia esos registros figura en una tabla de mapeo que puedes editar, y los campos que no arrastra son el ticket de soporte número uno en la categoría "¿a dónde fueron mis datos?". Este artículo es para el administrador que agregó un campo personalizado a Consulta y quiere que Convertir lo arrastre, o que quiere cambiar el rol de contacto predeterminado en las oportunidades nuevas. Al terminar podrás agregar o desactivar campos mapeados, cambiar los roles predeterminados por tipo de oportunidad, y entender los límites — los tres destinos permitidos, y el puñado de cosas que los mapeos no controlan.

Qué crea una conversión

Antes de personalizar el mapeo, ayuda ver qué produce realmente Convertir. Se ejecuta como una única acción de todo o nada — si alguna parte falla, todo se revierte y no se crea ningún registro.

El cuadro de diálogo te permite reutilizar registros existentes en lugar de crear duplicados — "Elija Cuenta existente O déjelo en blanco para crear una nueva cuenta." y "Elija Contacto existente O déjelo en blanco para crear un nuevo contacto." Esa reutilización es una elección manual deliberada, no una coincidencia difusa. Consulta Convertir una consulta para ver el flujo completo del usuario final.

En una ejecución sin problemas, el usuario ve "La consulta se ha convertido correctamente. Se le redirige al nuevo registro de oportunidad." y llega a la nueva oportunidad. Si la consulta ya estaba convertida, o el usuario no tiene permisos de conversión, el cuadro de diálogo se niega a abrir y muestra "Solicitud incorrecta. La consulta ya se convirtió o no tiene los privilegios necesarios para hacerlo. Póngase en contacto con el administrador del sistema." — un mensaje que los administradores atienden con la frecuencia suficiente como para tenerlo a mano.

La tabla de mapeo de conversión

Cada mapeo es un registro que dice "copia este campo de la consulta en este campo de este destino". Un registro de mapeo indica el campo de origen en la consulta, el campo de destino, el objeto de destino, y si está activo. El objeto de destino se limita exactamente a tres valores: cuenta, contacto y la oportunidad. Ese es el límite estricto — no puedes mapear un campo de la consulta directamente a un ticket ni a ningún otro registro.

REDA incluye 60 de estos mapeos, todos activos, repartidos entre los tres destinos: 5 a la cuenta, 12 al contacto y 43 a la oportunidad. Como la conversión solo lee las filas activas y las lee de nuevo cada vez, basta con agregar una fila para arrastrar un campo nuevo — sin código — y desactivar el indicador de una fila detiene la copia sin eliminar el registro.

Vale la pena destacar una fila: el campo Move In Date de la consulta se reparte en tres campos de la oportunidad a la vez — Close Date, Lease Start Date y Scheduled Move In Date. Es la prueba más clara de que un solo campo de origen puede alimentar varios destinos.

Este es el conjunto que va a la oportunidad, agrupado para facilitar la lectura (las filas incluidas son una lista plana; esta agrupación es solo para encontrar las cosas):

Los otros dos destinos arrastran muchos menos campos. La cuenta recibe 5 — el nombre de la empresa (del campo Company de la consulta), el teléfono, la región, y las referencias de tipo de consulta y trazabilidad. El contacto recibe 12 — nombre y apellido, correo electrónico, teléfono, celular, la dirección postal completa (calle, ciudad, estado, código postal, país) y una referencia de trazabilidad. Ese es el reparto detrás de la pregunta de conversión más común: los datos personales y de dirección llegan al contacto, los datos propios de la oportunidad llegan a la oportunidad, y solo un puñado de atributos compartidos llega a la cuenta.

Qué NO se mapea (y por qué los usuarios lo notan)

Dos categorías de datos "faltantes" generan tickets, y ambas son intencionales:

• Los datos personales nunca van a la oportunidad. Nombre, segundo nombre y apellido, correo electrónico, descripción y notas se mapean al contacto, no a la oportunidad. La oportunidad se vincula a ese contacto en lugar de duplicar sus datos. La atribución web y de marketing (cómo te encontró el prospecto) permanece por completo en la consulta — consulta Atribución web y de campañas.
• Tres campos cuyo texto de ayuda es engañoso. Maximum Allowed Offer, Commission Account y Commission Amount se leen como si se mapearan, pero no se incluye ninguna fila de mapeo para ellos. Maximum Allowed Offer aún aparece en la oportunidad porque esta lo recalcula con la misma fórmula — el valor se regenera, no se copia. Esa es la respuesta estrella de "explica la magia" de este artículo: nada se copió, y sin embargo el número está ahí.

Qué NO controlan los mapeos

Algunos comportamientos de la conversión parecen que deberían vivir en la tabla de mapeo, pero no es así. Cada uno tiene su propio lugar:

Roles de contacto predeterminados por tipo de oportunidad

Una segunda tabla, independiente, decide el rol predeterminado en un nuevo contacto principal — una fila por tipo de registro de oportunidad. El valor predeterminado se aplica solo cuando el rol se deja en blanco; un rol elegido manualmente nunca se sobrescribe. Y se aplica más allá de la conversión: cualquier rol de contacto nuevo con el rol en blanco recibe el valor predeterminado, porque esa lógica vive a nivel del registro, no en el botón Convertir.

Recetas

Arrastrar un campo personalizado

Dejar de arrastrar un campo

Desactiva el indicador de la fila en lugar de eliminarla — así queda documentada la intención. El cambio se aplica en la próxima conversión.

Cambiar un rol predeterminado

Edita el valor del rol en la fila de ese tipo de oportunidad dentro de la tabla de roles. Los roles de contacto existentes no se ven afectados; solo los registros nuevos con el rol en blanco reciben el cambio.

Un motor relacionado, pero independiente

Es posible que notes otras tablas de mapeo en Configuración que arrastran campos a registros que REDA crea a partir de una oportunidad — tickets y cargos de liquidación, por ejemplo. Esos son un motor distinto y ninguno de ellos toma su origen de la consulta. No los edites esperando cambiar la conversión; los artículos de tickets y facturación son los dueños de ese comportamiento.

Ejemplo práctico: arrastrar un campo personalizado

Meridian Properties agrega un campo personalizado Preferred Floor a las consultas de arrendamiento y quiere que aparezca en el contrato de arrendamiento resultante. El administrador crea un campo Preferred Floor equivalente en la oportunidad, y luego agrega un registro de mapeo — origen: Preferred Floor, objeto de destino: la oportunidad, campo de destino: Preferred Floor, activo. Convierten una consulta de prueba para Aisha Rahman (mudanza el 1 de agosto de 2026, plazo de 12 meses). El contrato resultante arrastra Preferred Floor; Close Date, Lease Start Date y Scheduled Move In Date muestran los tres el 1 de agosto de 2026 (el reparto de Move In Date en acción); y el rol de contacto toma el valor predeterminado Lessee.

Un segundo cambio, más pequeño: la inmobiliaria quiere que las oportunidades de Property Sale usen "Purchaser" como rol predeterminado en lugar de "Buyer". El administrador edita esa única fila en la tabla de roles — listo, sin efecto sobre las oportunidades existentes.

Qué sigue

1. Convertir una consulta — el flujo del usuario final y sus prerrequisitos.
2. Configuración global de la aplicación — los ajustes relacionados con la conversión a los que remite este artículo.
3. Configurar reglas de duplicados y fusión — el artículo hermano de configuración avanzada para administradores.
4. Atribución web y de campañas — por qué los datos UTM permanecen en la consulta.
5. Entender las consultas — el registro desde el que empieza la conversión.

Preguntas frecuentes