All of my projects available here:

  1. An efficient tool to Detect Deprecated API versions
  2. Query Performance Detector
  3. Multi-ORG Manager
  4. Dynamic Process Planner
  5.  Data Skew Detector
  6. License Usage checker
  7. Storage Notification Alert
  8. Trigger Framework Assessment
  9. Performance Assessment Dashboard
  10. Change Data Capture Assessment
  11. Protected Custom Metadata Type Assessment
  12. Apex Connector Framework Assessment
  13. BULK API V2 Assessment
  14.  Big Objects Assessment
  15.  JWT Bearer Token Assessment
  16.  Username/Password Authentication Flow Assessment 

All the source code available on this blog and my Bitbucket repository, I offer it to help others. Use it without restrictions. If it is not explicitly mentioned, I publish it under the MIT license.

📌 Use it at your own risk, and never directly in a productive ORG.

Todo el código fuente disponible en este blog, y en mi repositorio de Bitbucket, lo ofrezco, para que pueda ayudar a otros. Utilízalo sin restricciones. Si no se menciona explícitamente, lo publico bajo licencia licencia MIT.

📌 Utilízalo bajo tu responsabilidad, y nunca directamente en una ORG productiva.

An efficient tool to Detect Deprecated API versions

Salesforce regularly announces deprecating APIs. They provide instructions on how to identify applications making API calls into your org and what API version they are using.

The instructions though are manual and tedious as you can see here so, I created this tool to automate the process.

  • Detect REST and SOAP API based on Salesforce recommendations
  • Configurable N days inspection
  • Configurable threadshold API version
  • Login to Sandbox/Org via by token or connected App

.. and also:

  • Detect Apex Classes using deprecated API versions
  • Detect Apex Triggers using deprecated API versions
  • Detect LWCs using deprecated API versions

You can find an entry An efficient way to detect Deprecated APIs  in my Blog and the open source repo here.

Query Performance Detector

As our ORG grows, the queries we initially designed (which may have been optimized or perhaps not) can degrade. But I’m not just talking about Developers’ queries with SOQL; I’m also referring to List views, Reports, and Dashboards created by users.

Furthermore, this degradation occurs silently and unnoticed, only becoming apparent with performance issues in Production when it’s already too late. Corrective actions such as creating indexes, reorganizing data, etc. won’t be immediate.

You can find a blog post explaining this in Query Performance Detector, and the code is available in this repository QPD-SourceCode.

A medida que nuestra ORG crece, las consultas que inicialmente diseñamos (que quizás optimizamos o quizás no) pueden sufrir degradación. Pero no estoy hablando sólo de las Queries de los Developers con SOQL, estoy hablando de List  viewsReports y Dashboards que crean los usuarios.

Además, esta degradación se realiza en silencioinadvertida, y solo es visible con incidencias de rendimiento en Producción, cuando ya es demasiado tarde, y las acciones correctoras (creación de índices, re-organización de datos, etc.) no serán inmediatas.

Puedes encontrar una entrada del blog con su explicación en Query Performance Detector  y el código en este disponible en este repositorio  QPD-SourceCode.

Multi-ORG Manager

In a certain project, I needed to provide information about the licenses and usage of ORGs so that the client could have it updated regularly.

At first, I accessed each one to obtain the info by refreshing reports, consulting screens, etc., but soon found it repetitive and tedious. Analyzing the Salesforce API, I realized that it was possible to access much of the information I needed.

After analyzing the alternative, I confirmed that running queries on the appropriate Salesforce objects can obtain information from any application that can use the API.

This is a simple Java application to obtain data from Salesforce, and the Bootstrap framework to display the results in a user interface that doesn’t require any design skills.

You can find an explanatory post on Cuadro de mando multi-ORG and the complete, open-source code in this repository: Cuadro Mando MultiORG.

En cierto proyecto tuve la necesidad de proporcionar información sobre las licencias y uso de las ORG/s para que el cliente lo tuviera actualizado regularmente.

Al principio, accedía a cada una de ellas para obtener la info refrescando informes, consultando pantallas, etc., pero pronto me pareció repetitivo y tedioso. Analizando la API de Salesforce, me pareció que era posible acceder a mucha de la información que necesitaba.

Después de analizar la alternativa, confirmé que ejecutando queries a los objetos adecuados de Salesforce es posible obtener información desde cualquier aplicación que pueda utilizar la API.

Esta es una aplicación Java sencilla para obtener los datos de Salesforce, y el framework Bootstrap para mostrar los resultados en una interfaz de usuario, que no dependa de nula habilidad como diseñador.

Puedes encontrar una entrada explicativa en Cuadro de mando multi-ORG y código completo y libre en este repositorio: Cuadro Manto MultiORG.

Dynamic Process Planner

Despite Salesforce’s powerful asynchronous capabilities, I found the need to push the limits and improve the performance of Salesforce’s planner. That’s why I built a more aggressive and capable planner.

In this entry, Dynamic Asynchronous Process Planner and the complete code in this repository: Dynamic Planner.

Aún siendo muy potentes las capacidades asíncronas de Salesforce, encontré la necesidad de exprimir al máximo y con mejor rendimiento el planificador de Salesforce. Es por eso, que construí un planificador más agresivo y con más capacidades.

En esta entrada Planificador Dinámico de Procesos Asíncronos  y el código completo en este repositorio: Dynamic Planner. This repo is also available in English.

 Data Skew Detector

I don’t know if Salesforce offers any utility for locating Data Skew (data anomaly that causes serious performance problems), but anticipating what will happen in our ORG can save us a lot of headaches.

Therefore, I have developed a utility in APEX that allows you to analyze your ORG and find all fields with Data Skew. Sharing this information with your colleagues, users, administrators, or clients can save future problems and project costs. You can find an explanatory entry in Data Skew Detector y el código en este repositorio: Data Skew Detector Repo.

No conozco qué Salesforce ofrezca, ninguna utilidad para la localización de Data Skew (anomalía en los datos que produce problemas graves de rendimiento), aunque anticiparnos a qué suceda en nuestra ORG, puede suponer ahorrarnos muchos dolores de cabeza.

Por ello, he desarrollado una utilidad en APEX que permite analizar tu ORG, y encontrar todos los campos con Data Skew. Disponibilizar esta información a tus compañeros, a tus usuarios, a tus administradores, o a tu cliente, puede suponer ahorrar problemas futuros, y ahorrar costes al proyecto.
Puedes encontrar una entrada explicativa en Data Skew Detector y el código en este repositorio: Data Skew Detector Repo.

License Usage checker

Being aware of the use of your licenses is essential to avoid surprises and unexpected costs. Unfortunately, it doesn’t seem practical to regularly enter the ORG to evaluate it.

That’s why I researched how to automate the obtaining of this information through the Salesforce API. To obtain information on the use of licenses in the ORG, access is made through the UserLicense object.

You can find the post and code in this repository: License Usage Multiple ORGs Salesforce.

Estar al corriente del uso de tus licencias, es fundamental para evitar sorpresas y costes inesperados. Desafortunadamente, no me parece práctico entrar regularmente en la ORG para evaluarlo.

Por eso investigué como automatizar mediante la API de Salesforce la obtención de esta información. Para obtener la información del uso de las licencias de las ORG se accede mediante el objeto UserLicense .

Puedes encontrar la entrada y Código en este repositorio: License Usage Multiple ORGs Salesforce.

Storage Notification Alert

Salesforce does not send notifications when File or Data Storage hits the ORG limit, that’s not very convenient for an admin.

The Limits values are only exposed through REST API, no via standard object, to query it through SOQL No Packages found in App Exchange that are reliable and customizable, so I wrote mine, based on idea of bob_buzzard in  (Screen Scraper, what is scaring and challenging at the same time).

Open repository available here: Storage Notification Alert Salesforce.

Trigger Framework Assessment

Triggers are a fantastic feature in Salesforce, but as the project progresses and solidifies, their disorganized use can lead to inadvertent situations or unwanted side effects, frustrating both the developer and the user.

I studied the common issues that arise with triggers, as well as the best practices and frameworks that have been developed to mitigate them. I developed a series of articles on this topic:

  • A Simple yet Powerful Pattern: Analysis of Tony Scott’s Trigger Management Pattern,
  • The Appleman Framework that Started it All: Analysis of the Framework Published by Dan Appleman in his book Advanced Apex, which serves as a reference for many frameworks that appeared later, and finally, Hari
  • Krishman Framework, which evolved the concepts of the previous two and proposed an improved implementation of high quality.

The code used in these articles is available in these repositories: Trigger Framework Dan Appleman, Trigger Framework Tony Scott, y en este el código empleado para el Meetup: Meetup Framework Trigger.

Los triggers, es una funcionalidad fantástica en Salesforce, pero a medida que avanza el proyecto y se afianza, su uso desordenado provoca situaciones inadvertidas o efectos laterales indeseados, con frustración por parte del desarrollador y del usuario.

Estuve estudiando, cuales son las problemáticas habituales, cuando aparecen, y las best practices y frameworks que se han desarrollado para mitigarlas. Desarrollé una serie de artículos, al respecto: Un Patrón Simple pero Potente: Análisis del patrón de Gestión de Triggers de Tony Scott,  El Framework de Appleman que los inició a todos: Análisis del Framework que publicó Dan Appleman en su libro Advanced Apex, y que es la referencia para muchos frameworks que aparecieron posteriormente, y finalmente El Framework de Hari Krishman, que evolucionó los conceptos de los 2 anteriores, y propuso una implementación mejorada de gran calidad.

El código utilizado en estos artículos está disponible en estos repositorios: Trigger Framework Dan Appleman, Trigger Framework Tony Scott, y en este el código empleado para el Meetup: Meetup Framework Trigger.

Performance Assessment Dashboard

There is no possibility for an administrator to obtain the costs and Query Plans generated by the Optimizer from all Reports in a Salesforce Dashboard. Therefore, I wrote this code to obtain all the Query Plans of the Reports that each Dashboard Component of a Salesforce Dashboard contains. To do this, the explain resource of the Tooling API is invoked.

You can find the post on Query Optimization in Salesforce (Part 2) – with Query Plan and Tooling/REST API and the code in this repository: Get Query Plans for a Salesforce Dashboard.

No existe la posibilidad para un administrador de obtener los costes y Query Plans generados por el Optimizer desde todos los Reports de un Dashboard en Salesforce.
Por tanto, escribí este código para obtener todos los Query Plans de los Reports que contiene cada Dashboard Component de un Dashboard de Salesforce. Para ello se invoca el recurso explain de la Tooling API.

Puedes encontrar la entrada en Optimización de Queries en Salesforce (Parte 2) – con Query Plan y Tooling/REST API y el código en este repositorio: Get Query Plans for a Salesforce Dashboard.

Platform Capabilities Assessments

Change Data Capture Assessment

Protected Custom Metadata Type Assessment

Apex Connector Framework Assessment

BULK API V2 Assessment

Since I have extensively used this API to load large volumes of data, when version 2 appeared, I created a Java client to evaluate its performance compared to the initial version.

  • Explanatory input on BULK API v2: 2 times faster with half the code and complete and free code in this repository: Forcegraells-BulkApiV2.


Dado que he usado ampliamente esta API para cargar grandes volúmenes de datos, cuando apareció la versión 2, creé un cliente Java evaluar sus servicios y medir su rendimiento comparado con la versión inicial.

 Big Objects Assessment

Big Objects is Salesforce’s implementation of data containers, designed for massive ingestion, guaranteed query performance, and regardless of the volume of records (according to official documentation, whether it’s 1 million or 1 billion records).

Therefore, as massively sized data containers, they could initially apply to many use cases due to the large amount of data that companies generate. However, their limitations restrict the range of actual use cases.

For this reason, I created a project to test their usage and performance.

Explanatory entry on Big Objects: Data Containers – a «want to» and «maybe can» of massive storage in Salesforce and complete and free code in this repository: Forcegraells-BigObjects.

Big Objects es la implementación de Salesforce de contenedores de datos, para ingesta masiva, rendimiento garantizado de consulta e independientemente del volumen de registros (según la documentación oficial, sea 1 Millón o 1.000 Millones de registros).

Por tanto, como contenedores de datos de gran masivo, inicialmente podrían aplicarse a muchos casos de uso por la gran cantidad de datos que generan las compañías, pero sus limitaciones, restringen el abanico de casos de uso real.

Por ello, creé un proyecto, para probar su uso y rendimiento.

 JWT Bearer Token Assessment

 Username/Password Authentication Flow Assessment 

Anuncio publicitario
A %d blogueros les gusta esto: