• Skip to primary navigation
  • Skip to main content

Jorge Arrambide

Especialista en programación web en java

  • ¿Quién soy?
  • Contactar
  • Servicios
    • Programación para empresas
    • Asesorías de programación universidad
  • Articulos
    • Java
    • Salesforce
    • WordPress

Salesforce

Habilitar tab o ficha en Saleforce

Crear ficha, pestaña o tab en Salesforce

Al crear una ficha o pestaña (tab), en el ambiente de sandbox hay que seguir los siguientes pasos:

  • Crear el conjunto de salida (Outbound Change Sets) e incluir la ficha
  • Después de implementar la ficha en el ambiente productivo u otro sandbox, luego ir al Perfil en el cual se desea ver dicha opción.
  • En la sección Configuración de ficha personalizada, encontrar la ficha creada y cambiar el valor de Ficha oculta a Valor predeterminado activado.
Configuración de fichas (tabs) en Salesforce

Cómo validar campos en Salesforce

Existen diferentes maneras de validar un campo o atributo de un objeto de Salesforce, a continuación:

  • Validar a nivel de componente (javascript) los datos requeridos
  • Validar en el formato de página el dato obligatorio
  • A nivel del campo, colocarlo como obligatorio
  • Crear una regla de validación
  • Validar en Trigger

Validar a nivel de componente mediante javascript

Validaciones de campos mediante javascript

Mediante javascript se pueden validar un conjunto de entradas (mediante la funcion reduce) o bien de manera individual, es decir, un componente a la vez. (Ej. direccionEstado).

Validar en el formato de página

En la sección de configuración, en el gestor de objetos, al crear un formato de página, es posible hacer el campo obligatorio.

Marcar como obligatorio un campo de un objeto.
Al dar clic en el icono de la herramienta.

Validando directamente en el campo o atributo del objeto

Mediante el gestor de objetos, accediendo a los campos, es posible habilitar la opción obligatorio.

Validar dato requerido directamente en el campo del objeto

Crear una regla de validación

Es una de las formas más practicas de validar un campo, es mediante la regla de validación.

Reglas de validación para un campo

Validar datos mediante un trigger

Mediante el trigger del objeto, también es posible realizar la validación, mediante el método addError, del campo:

Método addError para agregar la descripción del error.

Límites de los eventos de plataforma estándar

Dejaré esta entrada como recordatorio y como evidencia de como se comporta el límite de 50,000 eventos diarios de Salesforce, con suscripciones mediante componentes Lightning.

Primero que nada, para saber cuantos eventos has consumido diariamente, solo se puede hacer mediante la API REST de Salesforce, si aún existe la herramienta workbench de salesforce gratuita, la cual tiene acceso a esta API, lo puedes hacer de la siguiente manera:

Tienes que ir al menú Utilities, REST Explorer y seleccionar lo que muestro en la siguiente imagen para ver los límites de Salesforce.

Luego damos clic en DailyStandardVolumePlatformEvents, con esto podremos ver la cantidad máxima de eventos estándar por día, en este caso el límite es de 50,000 y la otra cantidad son los eventos que quedan disponibles.

El problema o detalle, como lo quieras ver, es que esa cantidad restante NO SE RESTABLECE a medianoche o luego de transcurrir 24 horas, entonces, ¿cómo funciona el límite diario de los eventos estándar?, ¿cuándo se restablece el valor?

Aquí mis conclusiones: conforme se crean eventos en Salesforce, el “restante” va disminuyendo, y esa es la cantidad que de eventos que te quedan para crear. Según la documentación de Salesforce, según la licencia de tu organización tienes un límite por día y por hora.

Esperaba que luego de 24 horas esa cantidad se restableciera de un solo golpe, pero no ocurre así, sino que el “restante” se va incrementando según pasan las horas. Lo que me hace suponer que al crear un evento, éste tiene una vida de 24 horas, con lo cual el restablecimiento sucede conforme esa vida del evento.

Evidencia 1.- Restante: 1812 a las 7:20 am
Evidencia 2.- Restante: 2272 a las 9:00 am

¿Qué se toma en consideración para disminuir la cantidad restante?

Suponía que al momento de crear un evento en Salesforce, como se muestra en las siguientes imágenes, el contador (Remaining) empezaba a disminuir:

1.- Primero creamos el objeto evento en Salesforce

2.- Una vez creado e inicializado el objeto estándar, hacíamos la publicación del evento.

La forma en que Salesforce empieza a disminuir la cantidad restante de eventos (por lo menos en las suscripciones mediante componente Lightning), es mediante el atributo empApi, que se implementa en el componente de lightning que hayas creado.

3.- Cada vez que se crea un evento, la función callback es invocada

Cada vez que se publica (publish) un evento, la función callback es invocada y allí es donde realmente empieza a disminuir el contador de los eventos.

Ahora, imagina que tienes a dos usuarios cada uno en un navegador diferente, en la misma página en donde se realiza la suscripción y ambos clientes están “escuchando”, a la espera de eventos, bueno pues una vez que se hace la publicación (publish) del evento, en ambos navegadores se despliega el evento, con lo cual en lugar de que se haya descontado un solo evento, se disminuyen dos. Con cada navegador abierto, en la página donde se usa el componente para “escuchar” los eventos, se consume un evento.

Un ejemplo más sencillo, supongamos que ahora son 10 usuarios cada uno en su navegador, en la misma página de Salesforce en donde se tiene el componente que se suscribe a la espera de algún evento, se hace un EventBus.publish, (imagen 2) y luego el componente que esta “escuchando” gracias a que ya esta “suscrito” (imagen 3), detecta que se publicó un evento y lo “muestra” o “ejecuta” en cada uno de los navegadores, con lo cual la cantidad restante (Remaining) de DailyStandardVolumePlatformEvents , se disminuye en 10.

Compartir archivos y bibliotecas entre usuarios en Salesforce

En Salesforce es posible subir archivos (imágenes, documentos, etc.) y compartirlos con los mismos usuarios del CRM o con grupos públicos.

En el caso de que quieras compartir archivos, lo recomendable es crear una biblioteca, que viene a ser una carpeta, en donde colocarías los archivos que quieras compartir.

A continuación te describo los pasos para crear una biblioteca de archivos y como administrar sus permisos.

Crear una nueva biblioteca

Seleccionamos el objeto Archivo o Files y se mostrará la siguiente pantalla, en donde crearemos una nueva biblioteca.

A continuación proporcionamos Nombre, Descripción y una imagen que representará dicha carpeta/biblioteca.

Gestionando los usuarios

Una vez creada la biblioteca, ya podemos cargar archivos, pero si queremos compartir el contenido de esa carpeta, damos clic en Gestionar miembros

Veremos que hay dos tipos de miembros, los grupos públicos y personas. Y en el lado derecho tenemos los accesos, los cuales por default solo se tiene disponible Administrador de biblioteca, que tiene privilegios de Crear, Editar y Eliminar.

Habilitando más accesos a la biblioteca

Si queremos dar permisos o acceso de solo lectura, tendremos que habilitar dicha configuración de archivos mediante los siguientes pasos:

  1. Ir a Configuración
  2. Configuración de funciones
  3. Salesforce Files
  4. Salesforce CRM Content
  5. Habilitar la casilla “Activar Salesforce CRM Content“

Con el paso anterior, ahora tendremos habilitado más opciones en la sección de Acceso, como se muestra en la siguiente imagen:

¿Cuál es la diferencia entre controller y helper?

En el mundo de los componentes lightning nos encontraremos con los archivos controller.js y helper.js, si quieres hacer el mejor uso o mejor dicho las mejores practicas, aquí te detallo brevemente cual es la diferencia entre uno y otro y en donde deberías colocar tus funciones.

Supongamos que contamos un componente AccountList, el cual contiene a su vez el componente AccountCmp dos veces.

<c:AccountList>
   <c:AccountCmp id="1" />
   <c:AccountCmp id="2" />
</c:AccountList>

De manera visual el componente AccountList, se mostraría como en la imagen de la izquierda, pero mientras se ejecuta, se visualiza como en la imagen de la derecha.

Cada componente (paquete) esta compuesto por un marco (color amarillo), un archivo controller.js (verde), un helper.js (rojo), un renderer.js (morado) y otros.

Pero al momento de “estar corriendo”, el framework crea una instancia del controller, una instancia del renderer para cada componente, pero crea una sola copia del helper, y pasa la referencia del helper a cada instancia del controller y renderer.

Nota importante:
En caso de que tuviésemos diferentes componentes, por ejemplo, AccountItem.cmp y AccountDetails.cmp, cada tipo de componente tendrá su propio Helper, es decir, no se comparte como en el ejemplo anterior.

Ventajas

  • Dado que en Helper es compartido a traves de todos los componentes, nos permite compartir y mantener la lógica de Controllers y Renderers en un solo lugar.
  • También nos ayuda a mantener la lógica dentro de Controllers y Renderers “delgados”

Por lo tanto, debemos intentar delegar la lógica empresarial a los Helpers siempre que sea posible.

Por ejemplo, en lugar de tener lo siguiente:

// controller.js
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   var action = cmp.get("c.getAccounts"); 
   $A.enqueueAction(action); 
}

Deberíamos hacer lo siguiente:

// controller.js
callServer: function(cmp, helper) {
  helper.callServer();
}

//helper.js (compartido a traves de toda las instancias de controllers y renderers)
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   helper.callServer();
}

¿Cuándo usar Controller vs Helper?

  • Usa los Controllers para escuchar eventos de usuario y otros eventos como componentes, eventos de aplicaciones. Pero delega la lógica de negocio al Helper.
  • Delegar de manera similar en todas las funciones de Renderer (render, rerender, etc.).
  • Cuando necesites llamar a una función de controlador desde otra función de controlador, mueve esa lógica al Helper.

Anti-patrón

Demasiadas funciones en el Helper: si llegas a tener esta situación, lo más conveniente será refactorizar o descomponer el componente en subcomponentes más pequeños.

Variable global de javascript en controller o helper

No es posible declarar una variable global en los componentes lightning, específicamente en los archivos controller.js y helper.js, pero podemos crear un atributo ( aura:attribute ) en el componente que puede ser usado para almacenar información y puede ser usado en el controller o en el helper de manera global.

  • « Go to Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Go to Next Page »

Derechos de autor © 2025

  • Política de privacidad
  • Política de cookies
Este sitio web utiliza cookies propias para poder optimizar su visita a la página y cookies de terceros para recoger información sobre sus visitas y el uso de nuestra web. Vd. puede permitir su uso, rechazarlo o cambiar la configuración cuando lo desee. En caso de seguir navegando, se considerará que se acepta el uso. Más información: Política de Cookies