#salesforce flow bulkification | Explore Tumblr posts and blogs

premium-teaching · 3 years ago

Text

Complete Guide to Salesforce Flow Limits and How to Avoid Them

You can automate complex business processes and manual data entry with the help of flows.

By saving users time and ensuring that all necessary tasks are executed correctly, flows allow you to work smarter while reducing hard labour. Learn about 'generic' and 'Governer' constraints to take your Salesforce abilities to the next level. These restrictions can appear frightening at first, but understanding the most important concepts and constraints, as well as how you can avoid hitting Salesforce flow limits makes this process more simple.

Flows are one of the most powerful tools for Salesforce admins; when set up right, they are like a blessing to your sales team; but, if your flows aren't built appropriately, they may be tough to maintain and it will be a mess for your whole team.

Important factors every Salesforce professional must know

Why are there limitations on flows?

Salesforce works as a multitenant environment, which implies that the resources of the same instance are shared by numerous businesses. Salesforce has imposed certain constraints on each client's use to ensure that no one uses too much space. This is why there are limitations on flows.

Interviews and transactions

An interview represents a running instance of a flow which is also a complete run of that flow.

A transaction is a collection of operations that are all performed at the same time. Aside from triggers, escalation rules, and other forms of activities, flow interviews are also a part of them.

As a result, a flow interview is constantly active within a transaction.

Numerous flow interviews can be run in the same transaction, and a single flow interview can also be run in multiple transactions. The first is possible due to Flow bulkification, while the second is dependent on what constitutes a "single unit." we will them in more detail later. For now, keep in mind that a flow interview is not the same as a transaction, and different limits apply to it.

SOQL and DML

SOQL and DML are two separate languages that deal with different tasks. SOQL is used to get data, whereas DML is used to edit data. Only the data elements (the pink ones) will utilise these operations in Flow — "Get Records" uses SOQL, and "Create/Update/Delete Records" uses DML with minor variations.

Commonly occurring limitations

The limitations you'll most likely hit in the early stages are listed below.

Limits per-flow interview

Executed elements at runtime per flow: 200

There are a maximum of 2,000 elements that can be executed for each flow interview.

If you have a loop, then the components within the loop (including the loop element) will be multiplied by the number of iterations.

For example, if 100 records enter a loop with two elements, then the total number of elements is 200.

Limits per transaction:

Total no. of SOQL queries issued: 100

Ø you can only use a maximum of 100 data elements that can retrieve the data.

Total no. of DML statements issued: 150

Ø There are a total of 150 data elements that can be used to change the data.

Ø (Note that if these components are within the loop, they will be multiplied as well, which is why the best practice which is frequently used is "No Pink in Loop.")

Total no. of records pulled by SOQL queries: 50,000

Ø A maximum of 50,000 records can be retrieved.

Total no. of records processed due to DML statements: 10,000

Ø A total of 10,000 records can be modified.

Max CPU time on the Salesforce servers: 10,000 milliseconds

Ø The amount of time it takes for the servers to process your solution is referred to as CPU time. The maximum amount of time is 10,000 milliseconds (10 seconds).

Total no. of duplicate updates permitted in one batch: 12

Ø The same record can only be updated a total of 12 times.

Preventing hitting limitations

First of all, ensure that the flow is built in the most efficient manner. Even after following all the best practices, the flow still keeps hitting limits.

What will you do?

The limits are per-flow or interview, hence you can generate multiple flow interviews or transactions.

Building coherent flows

Planning on how to avoid hitting limits is great!

Hence, follow the below-given steps and you will never have to face the problem of the limitations again.

Excessive use of data elements should be avoided.

Try to avoid using the data element in a loop.

Avoid the loop if possible.

Entry criteria should be strict.

To update records, use variables and the Assignment element.

More flow interviews must be generated

When you are dealing with enormous amounts of data, then you are bound to reach the element limit first, followed by the number of records limit.

You can use the bulkification functionality of the Record-Triggered (RT) and Schedule-Triggered (ST) flow to avoid this.

Bulkification can be a little complicated, however, keep these things in mind to make it simpler:

Build your RT/ST flow as though the triggering item is a single record.

Salesforce will batch the records whenever possible.

This can help you effectively evade the element limitation.

Generating more transactions

You could reach the transaction limit even if you avoid the flow interview limit. You can try to avoid this by generating numerous transactions.

To return to the notion of "single unit," we can think of it as activities that can be completed without pausing.

The flow interview will be paused by screening items, planned pathways, and pause actions. The remainder of the flow interview will then be completed in a separate transaction.

This is a handy skill to have, but keep in mind that after a transaction is completed, you can't undo the operations because they have already been committed.

To wrap it up, Salesforce Flow limitations are imposed to ensure that all clients have an equal opportunity to use the resources. Normally, there are two types of limits (per-flow interview and per transaction), which are two separate and complex theories. But you can build the flows as effectively as possible, use the bulkification tool, or separate the transactions to circumvent these limitations and evenly distribute resources among all the users without disturbing the flows.

Founded in 2015, Premium Learning Systems have established a strong foothold in the domain of training with our phenomenal results. Till date, more than 25,000 students have been a part of this journey that has enhanced their skills and enlightened their career paths.

We offer a Career Accelerator Program (C.A.P.) which is an intensive 12 week online training program conducted by Premium Learnings to enable the professionals for the Premium-IT industry even if they are coming from a non-IT background.

For any Queries Contact us:- https://premiumlearnings.newzenler.com/contact-form/

If you are interested in Salesforce you can join our Career Accelerator Program (C.A.P).

Click the link and join the course: https://www.premiumlearnings.com/cap/

#bestitcourses ittraining ittrainingcourses itcoursesforbeginners itcourseforfreshers itinstituteforbeginners bestitinstitute professionalitc

0 notes

tak4hir0 · 5 years ago

Link

Enterprise Design Patterns have been around for a while to represent best practices for large scale development projects. First promoted by Martin Fowler in 2003 – “Patterns of Enterprise Application Architecture”. First Adapted to Salesforce by Andy Fawcett in 2014 – now known as “Salesforce Lightning Platform Enterprise Architecture, 3rd edition” Agenda Review basic Object-Oriented Analysis and Development themes Salesforce Lightning Enterprise Architecture patterns Selector Pattern Domain Pattern Service Pattern Unit of Work Pattern Application Factory Pattern Review of Apex Enterprise Patterns Open Source group and frameworks Apex Enterprise Design Patterns Open Source Frameworks originally created by FinancialForce FFLIB Apex Mocks An Apex mocking framework for true unit testing in Salesforce, with Stub API supportBased on the Java mocking framework Mockito FFLIB Apex Commons Framework which supports implementation of various Martin Fowler design patternsFFLIB frameworks are now maintained by the Apex Enterprise Patterns GitHub group https://github.com/apex-enterprise-patterns Basic OOAD Themes Various principles and themes used in enterprise application development: Separation of ConcernsDRY PrincipleSOLID PrincipleDependency Injection Separation of Concerns Enterprise software needs to change over time. It evolves.It’s one thing to write code to satisfy the immediate need. It’s another thing to write code that will be easy to maintain and be able to be changed over time.Complex code will become unmaintainable if proper boundaries are not established Typical layers include: Presentation Declarative: Lightning UI/LEX, Page layouts, Reports, Dashboards, Screen Flow Types Programmatic: Lightning Web Components, Aura, Single Page Apps, Visualforce Business Logic Layer Declarative: Certain elements of Flows and Process Builders, Approval Processes Programmatic: Apex Data Access Layer Declarative: Flow Data Elements – Create Records, Update Records, Get Records, etc Programmatic: SOQL, SOSL, Salesforce REST and SOAP APIs Database Layer Declarative: Custom Objects, Fields, Relationships, Autolaunched Flow Types Programmatic: Apex Triggers DRY Principle “Don’t repeat yourself” “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” SOLID Principle Single-responsibility principle A piece of logic should only have a single responsibility….and that responsibility should be entirely encapsulated by the class, module or function. Open-closed principle “Software entities … should be open for extension but closed for modification.” Liskov substitution principle “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” “Design by Contract” Interface segregation principle “Many client-specific interfaces are better than one general-purpose interface.” Don’t force a class to depend on methods that it does not use. Dependency inversion principle “Depend on abstractions and not concretions” Dependency Injection Technique in which an object receives things that it depends on at runtime. Separates the creation of a dependency from the usage of a dependency Promotes the concept of “loosely coupled” system Selector Pattern A class responsible for all aspects of queries for a single SObject. It manages the fields to query and manages the specific queries. All classes use this class to make queries against this SObject. The pattern encourages bulkification. All method parameters are usually Sets of IDs and return Lists of the SObject. Returns List of SObjects or Database.QueryLocator. Domain Pattern A class responsible for the business logic specific to a single SObject. Sometimes viewed as “fine grain services”. It is a wrapper around the records you are working with. Initialize the domain class with all of the records of that type that you are working with in the current context. This can be one to many records. It does not manage the persistence of records (see UnitOfWork). Handles defaulting and validations. Once you have the domain class, you work with a single object, executing logic on the records. Service Pattern A class responsible for aggregating the logic across multiple SObjects Sometimes viewed as a “course-grained service” This is the traditional “Service Tier Contract” boundary All Presentation or “client-tier” logic calls the Service Tier logic Typically, the “client-tier” logic only calls a single Service method per transaction Becomes the DML Transaction boundary by utilizing a UnitOfWork (see UnitOfWork pattern) Unit Of Work Pattern A “utility” class focused on Optimizing DML interactions with the Database layer Providing transactional control for the Service Layer Simplifying the complex code usually constructed to manage bulkified DML operations Managing the “plumbing” needed to save parent-child data relationships Used within a service method but passed to domain methods as needed. The UOW manages all DML transactions and rollbacks for all Service Layer logic Using an instance of UOW, you can register new records, modified/dirty records, and register records that need to be deleted. Once all records and changes are collected, the “commitWork()” method is called to begin DML transactions. UOW manages relationships between parent and child records Since the UOW only holds records until the end of the Service method and the call to the “commitWork()” method, it needs to maintain the “connection” between parent and child records. The “registerRelationship” series of methods accomplish this. Reference line 54 of the InvoicingServiceTest class. The parent Opportunity record is registered at line 39 …but not saved to database yet Each of the child OpportunityLineItem records are Registered as new records to be saved at line 55 Related to the parent Opportunity record at line 54 using the “registerRelationship” method During the “commitWork()” method execution, the UOW saves the parent Opportunity records, maintains a link to the new opportunity record id, and then adds that parent record id to the child OpportunityLineItem records before saving those new records. Recording Date : Sat, AUG 22, 2020 10:00 AM EST (7:30 PM IST) Where : Apex Hours Youtube Live Speaker : John M. Daniel Further learning Apex Enterprise Patterns — Separation of Concerns https://andyinthecloud.com/2012/11/16/apex-enterprise-patterns-separation-of-concerns/ Apex Enterprise Patterns — Selector Layer https://andyinthecloud.com/2013/09/09/apex-enterprise-patterns-selector-layer/ Apex Enterprise Patterns — Domain Layer https://andyinthecloud.com/2013/04/24/apex-enterprise-patterns-domain-layer/ Apex Enterprise Patterns — Service Layer https://andyinthecloud.com/2013/02/11/apex-enterprise-patterns-service-layer/ Apex Enterprise Patterns — Unit Of Work http://andyinthecloud.com/2013/06/09/managing-your-dml-and-transactions-with-a-unit-of-work/ http://andyinthecloud.com/2014/07/17/doing-more-work-with-the-unit-of-work/ Apex Enterprise Patterns — FinancialForce Apex Common Updates https://andyinthecloud.com/2014/06/28/financialforce-apex-common-updates/ 123 total views, 123 views today The post Apex Enterprise Patterns appeared first on Apex Hours.

#Apex Hours

0 notes