Personalizar los objetos de REDA
Puedes extender los objetos de REDA libremente: agregar un campo personalizado a Property, colocarlo en un formato de página, agregar un tipo de registro, escribir una regla de validación. Todo eso es personalización estándar de Salesforce, así que este artículo mantiene la mecánica breve y remite a la documentación de Salesforce. Lo que cubre en detalle es la parte propia de personalizar REDA: no puedes reescribir los campos y reglas empaquetados de REDA, y no deberías pelear contra la automatización integrada de REDA. Al terminar de leerlo, sabrás cómo extender los objetos de REDA de forma segura sin romper las actualizaciones ni la automatización que hace funcionar el producto.
Acceso que necesitarás. Permisos de administrador de Salesforce (Personalizar aplicación). Ten en cuenta que REDA ya incluye sus propias páginas de registro Lightning por tipo de registro — por ejemplo, las seis páginas de Oportunidad — así que ajustarlas es trabajo del generador de páginas del lado de la organización.
Qué puedes personalizar
En un objeto de REDA — Property, Oportunidad, Inquiry, Ticket, y el resto — puedes hacer todo lo que harías en cualquier objeto de Salesforce, junto a lo que REDA incluye:
- Agregar campos personalizados y colocarlos en formatos de página.
- Crear tus propias vistas de lista en cualquier objeto de REDA — vistas guardadas y filtradas de Properties, Oportunidades, Inquiries o Tickets para tu equipo.
- Agregar tus propios tipos de registro y sus Paths.
- Agregar reglas de validación (con cuidado — ver más abajo).
- Crear tipos de informe personalizados para reportar sobre los datos de REDA.
- Clonar y asignar tus propias páginas de registro Lightning. REDA incluye una página de registro por objeto y tipo de registro; puedes crear tu propia versión del lado de la organización y asignarla.
Ninguna de estas acciones toca los componentes empaquetados propios de REDA — se colocan junto a ellos — así que todas son seguras. El resto de este artículo trata sobre las dos líneas que no debes cruzar: no editar lo que REDA incluye, y no agregar una regla que pelee contra la automatización de REDA.
Qué no puedes cambiar
REDA se entrega como un paquete gestionado (managed package) — un conjunto sellado de componentes controlado por el proveedor. Esa protección tiene una consecuencia ineludible que debes interiorizar:
Esa misma protección implica que las actualizaciones vuelven a entregar los componentes empaquetados de REDA. Si editas directamente uno de los formatos de página o páginas de registro empaquetados de REDA, una actualización posterior puede sobrescribir tu cambio. El patrón seguro: crea tus propias páginas de registro en lugar de esperar que las ediciones a las de REDA sobrevivan a una actualización.
No pelees contra la automatización de REDA
Los objetos de REDA llevan una automatización integrada intensa — la lógica que avanza la etapa de un negocio, genera facturas y estampa los historiales de propiedad. Esa automatización no tiene un interruptor para omitirse: no existe una configuración que la desactive para un objeto o transacción dado. Eso importa en el momento en que agregas tus propias reglas:
Dos hábitos te mantienen a salvo. Primero, no dupliques ni contradigas las propias validaciones de REDA — REDA ya aplica sus reglas de negocio (por ejemplo, las verificaciones de precio, fecha y binder en una Oportunidad) mediante reglas de validación empaquetadas, y una regla tuya que compita puede entrar en conflicto. Segundo, cuando quieras que un campo sea obligatorio, da preferencia a marcarlo como obligatorio en el formato de página en lugar de usar una regla de validación estricta, para que la automatización de REDA pueda seguir escribiendo registros que no pasan por la interfaz.
Tipos de registro y Paths que incluye REDA
Un tipo de registro es una variante de un objeto con sus propios valores de lista de selección y formato; un Path es la escalera de etapas o estados que se muestra en la parte superior de un registro. REDA incluye varios de cada uno, y están empaquetados — extiéndelos alrededor, no intentes reescribirlos:
- Oportunidad incluye seis tipos de registro — Acquisition, Leasing, Lending, Property Management y Property Sale están activos, cada uno con su propio Path.
- Inquiry incluye seis tipos de registro con sus propios Paths.
- Ticket incluye dieciséis Paths específicos por tipo de registro.
Agregar tu propio tipo de registro y Path está bien. Pero las escaleras de etapas que incluye REDA, y las reglas de bloqueo que las protegen, están empaquetadas — construye junto a ellas.
Buenas prácticas para campos personalizados
Algunos hábitos específicos de REDA mantienen limpios los campos personalizados:
- No hagas sombra a los campos de REDA. Evita nombrar tu campo de forma que choque con uno de los campos empaquetados de REDA o con sus campos auxiliares gestionados por el sistema (los que la automatización de REDA escribe por ti — ver Gestión de datos para objetos REDA). Hacer sombra genera confusión y puede chocar con la automatización.
- Campos de moneda y multimoneda. Si agregas un campo de moneda y tu organización usa múltiples monedas, ten en cuenta que REDA estampa la moneda de un registro a partir de su Region. Alinéate con eso en lugar de anularlo (ver Comportamiento multimoneda).
- Otorga tú mismo la seguridad a nivel de campo. Un campo personalizado nuevo es invisible hasta que le otorgas acceso del lado de la organización. Los conjuntos de permisos de REDA no incluyen tus campos automáticamente — otorga la seguridad a nivel de campo mediante el perfil o un conjunto del lado de la organización.
Personaliza el objeto de tu edición
REDA se entrega en dos ediciones con nombres de objeto distintos. En la edición OEM (Platform) los registros de prospecto, negocio, servicio y marketing son los objetos personalizados de REDA Inquiry, Oportunidad, Service Request y Promotion. En la edición ISV (Sales Cloud) son los objetos estándar Lead, Oportunidad, Caso y Campaña. Personaliza el objeto de tu edición — un campo personalizado que agregues en el Inquiry de OEM no tiene una contraparte automática en el Lead de ISV (ver Ediciones: OEM vs. ISV).
Personalización segura vs. insegura, de un vistazo
| Acción | ¿Segura? | Nota |
|---|---|---|
| Agregar un campo personalizado a un objeto de REDA | Sí | Otorga la seguridad a nivel de campo del lado de la organización; no hagas sombra a campos empaquetados o del sistema |
| Agregar el campo a un formato de página / crear tu propia página de registro | Sí | Clona la página de registro de REDA en lugar de editar la empaquetada |
| Agregar un tipo de registro y Path nuevos | Sí | Extiende; no intentes editar los tipos de registro o Paths empaquetados de REDA |
| Agregar una regla de validación | Con cuidado | Pruébala contra los flujos de REDA — una regla puede bloquear las propias actualizaciones de etapa de REDA |
| Marcar un campo como obligatorio | Con cuidado | Da preferencia a lo obligatorio a nivel de formato en lugar de una regla estricta, para que la automatización pueda seguir escribiendo |
| Editar un campo / regla / tipo de registro / Path empaquetado de REDA | No | Paquete gestionado: bloqueado, no es posible |
| Activar el tipo de registro Booking de Oportunidad, inactivo | No | Inactivo en ambas ediciones — no compatible |
Ejemplo práctico: agregar un campo a Property
Meridian Properties quiere un campo Referral Source Detail en Property. Así es como agregarlo de forma segura:
Qué sigue
- Gestión de datos para objetos REDA — campos gestionados por el sistema, importaciones y exportaciones.
- Comportamiento multimoneda — cómo REDA estampa la moneda a partir de Region.
- Ediciones: OEM vs. ISV — qué objeto estás personalizando en cada edición.
- La Consola de administración de REDA — la torre de control del administrador.
Preguntas frecuentes
Sí — agrega campos personalizados, colócalos en los formatos de página, agrega tipos de registro y crea tipos de informe. Recuerda otorgar la seguridad a nivel de campo del lado de la organización; los conjuntos de permisos de REDA no incluyen tus campos automáticamente.
No. Los componentes empaquetados de REDA están gestionados y bloqueados. Solo puedes agregar los tuyos junto a ellos.
La automatización de REDA no tiene forma de omitirse. Una regla que bloquee una actualización de etapa o de registro propia de REDA hará fallar el flujo. Prueba las reglas nuevas en un sandbox y da preferencia a marcar los campos como obligatorios en el formato de página en lugar de usar una regla estricta.
No. Está inactivo en ambas ediciones y no es compatible. Déjalo inactivo.
Las ediciones hechas a las páginas empaquetadas de REDA pueden ser sobrescritas por una actualización. Crea tus propias páginas de registro para que tus cambios se mantengan.
¿Te resultó útil?