Retriving all Active Picklist field values in an Object using SOQL

SELECT Label
FROM PicklistValueInfo
WHERE EntityParticle.EntityDefinition.QualifiedApiName = 'Contact' 
AND EntityParticle.DeveloperName = 'ResourceRole'
AND isActive = true
ORDER BY Label

Architecture Patterns

𝐖𝐡𝐚𝐭 𝐚𝐫𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐚𝐥 𝐏𝐚𝐭𝐭𝐞𝐫𝐧𝐬?
Architectural patterns are standard strategies that define structural organization for software systems, providing a template for the architecture’s design and module interactions.

Here are famous architectural patterns:
𝐄𝐯𝐞𝐧𝐭-𝐃𝐫𝐢𝐯𝐞𝐧: An event-driven architecture is a framework that orchestrates behavior around the production, detection, and consumption of events. Example use case: A real-time analytics system where events are generated by user activities and processed immediately.

𝐋𝐚𝐲𝐞𝐫𝐞𝐝: A layered architecture is a hierarchical pattern for structuring a system into groups of related functionalities, each layer having a specific role. Example use case: A web application with a presentation layer, business logic layer, and data access layer.

𝐌𝐨𝐧𝐨𝐥𝐢𝐭𝐡: A monolithic architecture is a traditional unified model for the design of a software program where all components are interwoven and interdependent. Example use case: A small-scale e-commerce website where the user interface, server-side application, and database are all on a single platform.

𝐌𝐢𝐜𝐫𝐨𝐬𝐞𝐫𝐯𝐢𝐜𝐞: Microservices architecture is an approach where a single application is composed of many loosely coupled and independently deployable smaller services. Example use case: A large-scale cloud-based application like Netflix, where each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

𝐌𝐕𝐂 (𝐌𝐨𝐝𝐞𝐥-𝐕𝐢𝐞𝐰-𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐞𝐫): MVC is a design pattern that separates an application into three interconnected components: the model, the view, and the controller. Example use case: A desktop GUI application where user interface data (view), data manipulation (model), and input control (controller) are separated to simplify maintenance and scalability.

𝐌𝐚𝐬𝐭𝐞𝐫-𝐒𝐥𝐚𝐯𝐞: The master-slave pattern is a model where one master component controls one or more subordinate instances, called slaves. Example use case: A database replication system where the master database manages writes and the slave databases handle read operations to distribute the load.

Flow Running User and Execution Context

Who’s running flow?

The running user of a flow is the user who launched the flow, which can either be the current user or the Automated Process user. The running user determines what a flow that runs in user context can do with Salesforce data.

All flows, with the exception of scheduled-triggered flows, will run as the current user. When you have DML actions in your flow (actions that either create, edit, or delete records), the current user running the flow is:

• The user who will be stamped as the record creator (in the case of record creation),
• The user who last modified the record (in cases of record update or deletion), or
• The user performing an action (in the case of a flow action, get records, or invoking a subflow).

If you’re debugging or troubleshooting a flow error, you’ll look for the flow to be run as the current user.

Additionally, platform event-triggered flows that are standard platform events are sometimes published by the Automated Process user. However, Apex Debug Logs will show the flows run as the Automated Process user regardless of whether the platform event-triggered flow was run by the current user or Automated Process user.

For scheduled-triggered flows, if your flow is saved with an API version below 53.0—and for API versions 53.0 or greater and without a designated workflow user—your scheduled-triggered flow will run as the Automated Process user. If you’re troubleshooting or debugging a flow error, Apex Debug Logs will show this as the Automated Process user

Machine requires regular maintenance; your Data needs care

Maximize Salesforce Investment -> (Data) Quality

Summary: Investing a little in your data quality can create wonders for your ROI in Salesforce.

Your Salesforce does not bring you the expected ROI because of duplicate records, empty Fields, outdated, or unused data. These are just some of the complaints heard salespeople making about Salesforce. We all agree the quality of the data in Salesforce significantly impacts the return on our investment in Salesforce.

Improving data quality is often ignored since it sounds like a very daunting and unrewarding task.
It doesn’t have to be. Getting started with data management in Salesforce can be created easily.

1) Data Quality Manager
2) Achievable goals
3) Cleanup days

1) Data Quality Manager
Making one person the data quality manager can already make a huge difference. It doesn’t have to be a full-time or highly specialized position. A well-experienced and dedicated super-user can already make a big difference. Of course, the person should get some time and resources to fill that role.

2) Achievable goals
“Better data quality” is a very lofty goal. Specific and achievable data quality goals are more helpful in maximizing the ROI of Salesforce.
A goal like “All active customers should have a working phone number.” is realistic and achievable.
Reaching a goal as quickly as possible can create data quality momentum.

3) Cleanup days
Excellent data quality is not made once and forgotten but needs constant cleaning. In the same way, a machine requires regular maintenance; your data needs care.
Putting aside a few quarterly days for data quality work can work wonders. Combined with a data quality manager & achievable goals, a few days per quarter can work wonders on your data quality.

Data Architecture & Engineering