this Q&A inspired by running into CPU Limits issues on very large async JSON payloads where 1000+ assets were created from JSON within an fflib framework and then evaluated by a complex Process Builder. Could the Process Builder be optimized to improve throughput? (ability to handle more than 1000 Assets per Transaction)
CAVEAT: YMMV - every org/app is ...
if your using any IDE, you get easily what flows are using apex classes.
Get flows files in to your local by using package.xml, we used VScode IDE
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
Could that be that when creating a new Quote, the fields for the object Quote Line Items have not been created yet?
That's it precisely. Like all child objects, Quote Line Items cannot be created until their parent, the Quote, is in place.
There are a few other solutions, depending on exactly what you're aiming to do. The most obvious to me, assuming that ...
You can have up to 50,000 flows waiting at any given time. Of those, up to 1,000 will be processed per hour. The list only shows 1,000 items, but the remainder should still be waiting. It will take a few hours for them to process. You can read more in Limitations for Waiting Flows.
A user logging in does not "modify" the User record in the traditional sense (the Last Modified fields are not updated, and no triggers or processes are executed). Instead, create a Login Flow if you wish to provide this sort of notification.
Process Builder and Flows are bulkified (e.g. you can safely update a field on 200 records at once), but they can't handle the situation where a single record is updated a large number of times in the same transaction (more than 12). Unfortunately, Flows and Process Builder aren't great at updating parent records in a bulk pattern, and there's no way to make ...
You should still be able to use Process Builder.
Remove the Is changed condition altogether and try marking the checkbox true on the Advanced -> "Do you want to execute the actions only when specified changes are made to the record?" as shown below:
This will effectively run itself on both insert and updates to the record's custom date field.
if suppose the Due Date =30 days, then will the Scheduled action for '40 days' be skipped and will move to execute '25 days' scheduled action or not ?
Assuming you make the change you're discussing and collapse the conditionality of scheduling these actions: No, the scheduled action for 40 days will not be skipped. It will be executed more or less ...
I figured it out- if an admin (or non-owner) profile with sufficient permissions changes the opportunity owner, the child task won't change owner. It's only if the record owner gives their record to someone else, that their task is automatically reassigned. Since we're using distribution engine, a separate automated account will be performing the actual ...