Logger in Flow questions

[vr8hub]

I've read the Readme multiple times and browsed the fields in the Log and LogEntry objects, but I'm still missing some information re how to use this in Flow. (No Apex development here, so this will be used purely in Flow.)

1. What is the optional "Save Log" field on the "Add Log Entry" action for, i.e. when would we use it or not, and if we do use it, what value are we putting in the field? (An additional screen print in the flow quick start that showed the parameters for that action might be helpful.)
2. A similar question for the "Save Log" action—the readme says it "saves any pending logs," but what makes a pending log? Do the other three "Add" actions only create pending logs and we need to use a "Save Log" each time we want to save? That doesn't sound right, but there's no other mention of "pending logs" re Flow, so I'm not groking what we use that action for.
3. The Add Log event takes a record ID, the "… for SObject" takes a record variable, and the "… for Sobject Record Collection" a collection variable, but what is the end-result difference in those? I didn't see a record ID field on the Log__c object, so what is Add Log Event doing with it? Are the other two actions actually storing the record(s) in LogEntry? I'm trying to get a handle on why we would use one vs. the other.

Thanks so much, and I apologize in advance if I missed where these were addressed.

[jongpie]

Hi @vr8hub - these are all great questions! And unfortunately, I have some gaps in the README, so some of this functionality is not currently documented as well as it should be. I need to spend some time working purely on documentation, so I'll shift focus to that in a few weeks by working on these 2 issues:

• Add wiki for documentation #15 - I started working on a wiki for the repo a while back, but never finished implementing it. I'm going to work on it again - a lot of the content in README will move into the wiki, and I'll expand the content with more details & screenshots
• Create a "recipes" package  #196 - I've slowly started working on this already, but it's not finished yet - I'll be creating an optional add-on package that contains some example metadata of how to use Logger in different scenarios

---

As far as your Flow-specific questions, here's some additional details - I'll eventually include some of this info in the wiki as well.

What is the optional "Save Log" field on the "Add Log Entry" action for, i.e. when would we use it or not, and if we do use it, what value are we putting in the field? (An additional screen print in the flow quick start that showed the parameters for that action might be helpful.)

Logger uses "platform events" to handle creating log entries - platform events are a special type of object within Salesforce. Just like Flow, platform events have some per-transaction limits. In this case, any time Logger saves log entries (from Flow, Apex, etc), it counts towards a Salesforce per-transaction limit called "'Publish Immediate' DML statements".

• To help avoid hitting the limit, Logger does not automatically save the platform events when you log something in Flow, It relies on you to tell it when it should save the log entries (this concept applies to using Logger within Apex as well).

• Until you have told Logger to save log entries, it internally stores them in a buffer - this buffer is the same thing as the "pending log entries" mentioned in README. If you don't tell Logger to save, then any of these pending log entries will be discarded/lost.

• The "Save Log" field on "Add Log Entry" is 1 way that you can tell Logger that you're ready for it to save the log entries

• If you are calling the "Add Log Entry" action multiple times in the same Flow, then you probably don't want to use the "Save Log" field every time - for simple Flows, you would probably only need to use it the last time you call "Add Log Entry" in your Flow. In this screenshot, the first action "Log Account Before Changes" creates a log entry, but does not save it - only the "Log Account After Changes" action has "Save Log" set to true, which saves the log entries from both actions

  

A similar question for the "Save Log" action—the readme says it "saves any pending logs," but what makes a pending log? Do the other three "Add" actions only create pending logs and we need to use a "Save Log" each time we want to save? That doesn't sound right, but there's no other mention of "pending logs" re Flow, so I'm not groking what we use that action for.

Great question, and this definitely relates to the previous question - keeping in mind that you have to handle telling Logger that you want it to save log entries, you can do so 2 ways:

1. The "Save Log" field (mentioned above) - all of the Flow actions ("add a log entry", "add log entry for an SObject record" and "add a log entry for an SObject collection") have this field available. Often times, this is the easiest option because it's all handled via the same action (i.e., you are adding a log entry and saving any pending log entries, using just 1 action)
2. The "Save Log" action provides the same functionality as the "Save Log" field - any pending log entries will be saved. The main benefit of this action is that sometimes in Flow, you may only want to ensure that pending log entries are saved - you may not always want/need to add an additional log entry at the same time, so this action is included as an extra way to control saving via Flow.

The Add Log event takes a record ID, the "… for SObject" takes a record variable, and the "… for Sobject Record Collection" a collection variable, but what is the end-result difference in those? I didn't see a record ID field on the Log__c object, so what is Add Log Event doing with it? Are the other two actions actually storing the record(s) in LogEntry? I'm trying to get a handle on why we would use one vs. the other.
All of these scenarios work very similarly, and the end result is that additional details about the record(s) are stored on the LogEntry__c object (not on the Log__c object directly) - this information is shown on the LogEntry__c record's page in a section called "Related Record" (see screenshot below)

• "Add Log Entry" action - this action was originally designed for scenarios where you just want to log a message with with Flow. However, when you use the optional Record ID field, the LogEntry__c record will automatically be related to the corresponding record
• "Add Log Entry for an SObject Record" action - this action will also relate the LogEntry__c record, but it also automatically logs the JSON of the record, at the time that the action is called. This is useful is storing/seeing all of record's field values at that point within the Flow. For example, you can build a Flow that calls this action with a record --> make some change to the record (e.g., change the record's name) --> call the action again - this will create 2 log entries. The first log entry will store the record JSON with the original field value, and the second log entry will store the record JSON with the updated field value.
  • Personally, if I want a log entry record to be associated with a particular record, I always try to use this action, instead of "Add Log Entry" - the record JSON is often very helpful in verifying what the record looked like at a particular point within the Flow
• "Add Log Entry for an SObject Record Collection" action - this action will not directly relate the LogEntry__c to a particular record. Instead, it stores the JSON of the entire list of records on the LogEntry__c record. Similar to the previous action ("Add Log Entry for an SObject Record"), this is useful in logging what a collection looks like before & after your Flow makes changes to the collection.

Here are some screenshots of where you can see the "related record" details

• "Related Record" field, shown on the Log__c record's page, within the related list of log entries
  

• "Related Record" section of additional fields, shown on the LogEntry__c record's page, including the "Record JSON" field
  

Hopefully this helps clarify on some of the functionality, but please let me know if you have any follow-up questions!

[vr8hub]

Excellent, thank you for the quick and detailed response! You didn't say explicitly, but you mentioned it in passing—the value we would put in the "Save Log" field is True? (As in the global variable, or just the word?)

Thanks again—everything you have there is very helpful and will be a great addition to the documentation.

[jongpie]

@vr8hub sorry about that! Yeah, you would use the global variable true for "Save Log". Here's a screenshot of what it looks like once configured:

Let me know if you need anything else!

[vr8hub]

Just some suggestions for the wiki when you get there:

1. I see now the README does talk about the various save methods, but only in terms of Apex, and it specifically cautions (for good reason) against using SYNCHRONOUS_DML. You might just mention them in terms of debugging problems, e.g. like not getting log entries, and for Flow as well as Apex.
2. A mention that it's important the flow API name be accurate (since that's what's being used to get the flow information for the log entry record). I know, I know, that should be intuitively obvious to the most casual observer :), but before that last problem I thought it was just used for reference.
3. What the default value is for Logging Level, i.e. if it's not specified. And you might give some high-level coverage of what the various values are and their hierarchy (or maybe just point them to SF docs?); for pure Flow admins, they may not have dealt with the different levels on the system logs.
4. Maybe an example of how to include Flow variable value(s) in a log entry. I assume we would have to create a formula with the various values concatenated together with a message, but having an example in the wiki might be helpful.

[jongpie]

@vr8hub this is some fantastic feedback! I'll definitely include these areas in the wiki - thanks for the suggestions! And as far as the default value for Logging Level, it will use 'DEBUG' if not specified within your Flow.

[jongpie]

@vr8hub another update on this - I've finished the first step of just creating the wiki by taking content from README and creating separate pages in the wiki. My next step is to start expanding on the content to incorporate additional details, including a lot of your questions/content from this issue.

It's definitely a work in progress, but I'll be actively working on expanding the wiki over the coming weeks. If you think of any other questions/details that you think should be added to the wiki, just let me know!