#Automation30 diskutieren mit

@Reno Redaja

Document Processing runs as an Agentforce agent action, so it isn't on a separate meter - it draws from your Agentforce Flex Credits (the same metered pool your agent actions use, billed monthly in arrears). Data Cloud has its own Flex Credits for Data Cloud operations, but the agent-action invocation itself is Agentforce credits. 

To see it, go to Setup > Digital Wallet - that's the central, near-real-time dashboard for Flex Credit consumption (agent actions, usage, balances). You won't find a line literally labelled 'Document Processing'; it shows up as the consuming agent's action usage, so read it there by agent/action. You can also add Consumption Threshold Alerts via a Flow to get notified as usage climbs. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks!

The reason those are landing on you rather than System is that they 

are not coming through Web-to-Case or Email-to-Case. They are coming 

in through the API via Zapier, and API-created records are owned by 

whichever user the integration authenticates as. If Zapier is 

connected using your credentials, that is you. 

The fix is to create a dedicated integration user, reconnect Zapier 

as that user, and the automated actions will show against it instead. 

Worth doing anyway from a security standpoint, since integrations 

running under a named admin account is a common audit finding. 

Disclosure: TwinStack, we build in this space. If you ever want to 

drop Zapier from that particular chain, the same principle applies: 

It uses a Run-As user you nominate, so you control record ownership 

explicitly.

Hi @Rohit .

Use a Roll-Up Summary (SUM) on Order to calculate the total Line Item Quantity if the relationship supports it; otherwise, use a Record-Triggered Flow to aggregate the child quantities. 

Trigger approval only when the total crosses 100, and use an Approval Status/Submitted flag plus an active-approval check to prevent duplicate submissions  

Hope This Helps!!

Hi Matteo , 

The best approach is to measure first and optimize the actual bottleneck rather than focusing on only Flow or Apex.

I would start with Salesforce Debug Logs and reproduce the slow record update. Then check:

1. CPU time – Look for high CPU consumption across the complete transaction.
2. SOQL queries – Avoid SOQL queries inside loops and make sure queries are selective.
3. DML operations – Bulkify inserts, updates, and deletes instead of performing DML repeatedly inside loops.
4. Flows – Check for unnecessary Get Records, Update Records, and large loops. Move queries outside loops and perform collection-based updates.
5. Apex triggers – Ensure triggers are bulkified and avoid repeated queries or DML.
6. Automation order – Review all Flows and Apex that execute during the same transaction because multiple automations can contribute to the same CPU and governor limits.
7. Scheduled automation – Review the volume of records processed and consider Batch Apex or other asynchronous processing for large workloads.

Short answer: For an APEX-defined Integration, the endpoint and authentication are not set inside the Integration Definition record itself — they're set inside your Apex.class that implements the DataSource.Load (or VlocityOpenInterface) interface. Inside that class's load() method, you build an HttpRequest and set the endpoint URL there, and for auth, best practice is to use a Named Credential (endpoint = callout:YourNamedCredential/path), so Salesforce handles the token/credentials instead of hardcoding them in code. 

In the Integration Definition, you only specify: 

• Type = "Apex Class"
• The name of the class implementing the interface
• The request/response JSON structure (so the Integration Procedure knows how to map the data)

Then in the Integration Procedure, you just drop in an "Integration Action" element pointing to that Integration Definition — it calls your Apex class, which handles the endpoint and auth internally. 

If you're using External Service Defined instead, the endpoint/auth is already configured via Named Credential when you set up the External Service itself (Setup > External Services) — no extra Apex needed in that case. 

Hi Dan - the app is Trail Tracker (Salesforce Labs, free on AppExchange). It syncs each user's earned + in-progress badges, points and trailmixes daily via an API integration user, lets you ASSIGN badges/trailmixes, and ships with pre-built reports and dashboards. So 'how many badges/points a user earned' and assigning learning are covered out of the box. 

The specific things you listed are NOT native, though: 

- Available points per badge (earned vs available): it syncs what's earned, not a catalogue of available points - you'd maintain that reference yourself. 

- Alerts when a completed badge is revised or gets new content: no mechanism. Trailhead doesn't surface 'this badge changed' through the sync. 

- Certifications: not synced. Certs aren't badges (they live in a separate system), so it won't pull them - track those manually or via a separate integration. 

- Quests: not a standard synced object either (quests are temporary badge campaigns). 

The upside: Trail Tracker is a Labs app, so you get the objects and code - you can extend it (custom fields for available points, a flow to flag changes, a custom object for certs) rather than build from scratch. Out of the box, though, it's badge/points/trailmix tracking + assignment, not the full picture you're after. 

If this helps, please mark it as the Best Answer so it points the next person the right way - 🙂