Name: Architecting Scalable Doc Gen with Flow, Apex & Platform Events
Uploaded: 2026-05-19T16:30:59.884Z
Duration: 1 h 3 min 16 s
Description: Architecting Scalable Doc Gen with Flow, Apex & Platform Events

Transcript for "Architecting Scalable Doc Gen with Flow, Apex & Platform Events": Alrighty. We are live. I am looking forward to seeing some, seeing some comments in the chat so you can let me know that you're here. Beautiful. We have React. We have a hello. There we go. There we go. How are we doing? Yes. Everyone, has seen the message from Mario. Comment in the chat where you're joining in from today. We always love to sort of see where where, where the audience is coming in from. There we go. There we go. Look at that. All around the world. Crazy. I might give a few more seconds, maybe twenty more seconds just for people to join. As you join, we're just sharing where we're joining in from around the world, just seeing where everybody's tuning in from. It's gonna be a great session today. We got the S Docs team coming in to talk about architecting document generation with Flow, Apex, and Platform Events inside of Salesforce. Oh, beautiful. Jimmy, Just, listening to me on the podcast. There we go. How's that? That's that's really good to have you here. Good to have you here, everybody. Alrighty. Alrighty. So, yes, we are gonna be talking today. Well, sorry. I'm not gonna be talking today. Don't worry. You're not gonna have to hear my, Aussie accent for too much longer. We got the S Docs experts coming in to talk about architecting document generation with Flow, Apex, and Platform Events inside of Salesforce. And with that, let's jump into it. And before we do, if you haven't sort of seen what we do before at Salesforce, Ben, you may have come across our articles. There's a lot more that we, that we do in the Salesforce space. We've got, of course, the newsletter as well. And if you haven't signed up, there's a banner on the site. You can go ahead and do that. That's so we can keep up to date on all the latest, information as it happens. We've got events as well. There's a sort of in person and online webinars as you're attending now, and we appreciate you being here. There's also the YouTube channel, of course, if you're if you're sort of a a visual learner, visual, you know, you like to sort of, see and hear things as they occur. I'm certainly one of those as well. And then, of course, there's the podcast. There's actually two podcasts. We got the Salesforce Ben Insider podcast and also the Picklist podcast that we do weekly as well. Alrighty. And, look, you know, myself, I should do a quick introduction for me. So I'm Tim Combridge, and I have been a technical content writer for Salesforce Ben. Well, sorry. That's only relatively new, but I've I've sort of been in and around the Salesforce Ben world, for a little while now. But, look, I'm gonna hand over to the stars of the show now from S Docs. Hannah and Mike, Hannah, I'll hand over to you. Hi, Tim. Thank you so much. My name is Nina Champagne. I've part of SPAX for about four years now, and I am, leading most of their implementation and onboarding services. So I've seen a lot of different applications of our product and applications of Salesforce in general across the ecosystem, and I'm really excited to be a part of this today and share a little bit more of the hands on demonstration portion of today's discussion. Joining me today is also our director of product management, Mike. Yeah. I will let him introduce himself. Thanks, Hannah. Yes. Hannah just said, I'm the director of product management for our Salesforce solutions at Estox. I've been with the company for about five years, and I've had the privilege, to really oversee a lot of the great development we've had with the Salesforce platform itself with all of their innovation. And what we're hoping to look at today is how you can use kind of the strengths of the platform itself, and then kind of synergizing that with the, the product that you're gonna see a lot of demos of today as well. But with that, first and foremost, I just wanna thank everybody for coming today. I see a lot of people from all over the world, so it's pretty exciting for us to be able to share, always an honor to talk about Salesforce and our products when we can, and really just share our thought leadership. But today, we're actually gonna approach document generation from a slightly different angle than you might be used to. Now most conversations about doc gen, they focus on how to generate a document. What we're gonna focus on today instead is how do you design document workflows so they actually scale with your business and they're much more resilient. This is really about architecture and how do you take something that starts as a simple action and turn it into a reliable, reusable service inside of Salesforce. Now why does document generation matter? Now document generation is one of those things that just sits quietly in the center of a lot of critical workflows. You might have quotes, proposals, agreements, service documents, compliance outputs. It's ubiquitous. They are often though the final step in any given process. And because of that, any inefficiency or inconsistency here, it tends to ripple outward, especially when you're starting to distribute these documents to your your audience. Now what we see a lot of teams investing heavily in is CRM process design, but document generation also continues to get treated as kind of an afterthought in the grand scheme of things. So most orgs, they start with a very reasonable place, button driven document generation. And to be frank, that works really well, until it doesn't. Now some of the common signals that we see when things are starting to break down with button driven, document generation is you might have multiple buttons doing slightly variations of the same thing. Templates are duplicated across teams or regions. You have business logic that might be embedded in too many places and just hard to answer simple questions like, where is this document generated from? So a lot of maintenance issues, a lot of headaches. At that point, the issue though really isn't the capability. It's the system hasn't been designed for reuse. So the shift that we're advocating for is to really start treating document generation as a platform service and not necessarily a UI action or interaction. What that means in practice, is you define consistent inputs, what data, context, whatever a document needs. You standardize how it's invoked, whether that's flow, Apex. Could very well still be a button if that's appropriate. And you centralize the governance, so all of your templates, the branding in those templates, all of your compliance logic. Instead of building document logic for every use case, you're now calling into a shared capability. And this is where native approaches and solutions like what you're gonna see here in just a moment with S Docs. They fit nicely because they operate directly within Salesforce. They can be invoked from all these different automation patterns without really needing to rearchitect each time. So once you think of document generation as a service, the next question really becomes how do we invoke it? Now I'll start by saying that there's really no one size fits all answer to this, and it's really just about choosing the right pattern for the right job. The phrase we like to say is you don't need a hammer when you need a screwdriver and vice versa. So we're gonna walk through four core patterns today and when each makes sense to invoke. And we'll start with the the basic one. This is the screen flow pattern, and these are really ideal for when you have a guided interaction. You wanna think about using this when the user needs to make some choices. You wanna collect inputs at runtime. There's some variability in the output. A really common example of this, is a guided quote or a document generation where, say, a field representative needs to select some options before generating the document. So the one that we see typically is, let's say you have a service call, that service representative, they go out to the customer's house, maybe it's a dishwasher repair, washing machine repair. They're selecting all of the parts and pieces of the invoice that needs to construct that invoice, and that's a dynamic input that gets represented in the final output. Now from an architecture perspective, this is still calling in that same underlying document service. You're just adding this UI layer on top that makes it more unique. And with something like S Docs, again, this becomes really straightforward because document generation is invoked directly from a flow without requiring any custom integration layers. So rather than I just describe this, I'm gonna hand the stage over to Hannah now who's gonna show us what this really looks like in practice. Great. Thank you so much, Mike. Before I jump into the ScreenFlow demo, I kinda just wanna set the stage for all of the demos we're going to be seeing today. So what we can see right now on my screen is an opportunity I set up for this webinar. It's just a mock placeholder opportunity, with some products loaded in. And the template that we're gonna use reuse for generation over all every single one of these demos today is our standard MSA over here on the right. This is an s docs template. And I think before I get into the ScreenFlow full demo, I think it's really important to kinda look at the the document we're working with today, so I can show how the choices I'm gonna make in the ScreenFlow are gonna change the output of this document. So I'm gonna go ahead and just generate our standard MSA really briefly here so we can take a look at it. And from there, we'll we'll kinda get a baseline of our document, and then we'll go ahead and generate it via the ScreenFlow and control some of the outputs here. So now on the screen, you can see our standard MSA. All of these blue fields up at the top here are actually data that's been pulled in from this opportunity. So, I think this is the account address. If you scroll down here, we have a quick summary of the product totals that are associated to this opportunity. And further down at the bottom, you know, we have some more information being pulled in from Salesforce, and we're also gonna collect some signature inputs on the document here. When we send this for signature, these these inputs will be rendered in the UI. I'm only gonna do the signing process for the first demo today. The rest of the architecture examples will just look at the document generation portion. Again, we're gonna be using the standard MSA for all the examples today. Alright. So without further ado, now let's look at how we could control that output a little bit more dynamically by, generating the same document via a screen flow. So I'm gonna go through the end user experience first, and then we'll open up the Flow Canvas very briefly and show how that's kind of architected under the hood. So up here in the top right, I have this, this button that I've mapped to the page called generate MSA with t's and c's. So I'm gonna use the ScreenFlow. When I click this, it's gonna launch my ScreenFlow. And now instead of just producing me the MSA, it's asking me which terms and conditions I'd like to include. For sake of example, I am gonna go ahead and choose both in this instance. I know that's really not probably something we do in real life, include both North America and Europe terms and conditions, but I just wanna show that choosing both will output both in the document. Just know that if I would have chose one or the other, we would only see one. And then again, this is all driven by Salesforce ScreenFlow. We'll take a look at the flow canvas here in another minute. So I'm gonna go ahead and generate the document now. I just have a disclaimer screen once this is done to say, hey. Your document's generated. So we'll give it a second to go ahead and do that. And then once we see that confirmation, we will go ahead and I'm just gonna click finish here and refresh the page. And we should see a second standard MSA, you know, in our generated documents LWC down here. So now let's take a look at this one. And you will see immediately that it has North American Ts and Cs at the top here and then right below it we have the Europe Ts and Cs. If I would have chose one or the other, only one would have shown here, but this is just a quick example showing how runtime inputs from the user via ScreenFlow can affect our document output. And then everything else we saw is the same as before. So like I said, I'm gonna just do the full demo here and send this for signature so we can all see what it looks like. For the other architecture examples, we'll just look at the document generation from here on out. So I'm gonna go ahead and choose the standard MSA we just, produced and click send here. We're gonna see an email model modal, sorry, pop up on the screen. And, everything inside this modal I apologize. Moving a little slow today. Everything inside this modal is powered by S Docs as well. So from the body of the email template all the way up to, you know, where this is going in the subject line, this is all powered by our FSTOCs email template. Just know that everything you see on the screen is also customizable. So I'm gonna go ahead and send that. I'm just gonna wait for it to give us a green light and say that the email sent successfully and then I will toggle over and do a very brief signing process. Successfully, and then I will toggle over and do a very brief signing process just so we could see again the end to end. And then we'll turn it back over to Mike to talk about our our next workflow here. So just give it a second here. I'm just looking for it to say that everything sent successfully. And there we go. Just gonna give it another couple seconds here before I go to my email and refresh it just to get it able to come through. Oh, perfect. That went pretty quick. So now you can see that exact email here. It's in my inbox. I'm gonna click here to sign. And now we're entering our, doc signing experience. We'll just briefly consent and do a signature and submit it back to Salesforce so we can see where it's saved to the the base record. I'm gonna consent to do business electronically. And now we will see the document that we just viewed in the signer interface, pulled up here. And like I said previously, those, signing fields when I scroll down here are now rendered appropriately. So, just quick note here, we can collect a few other things other than signature, like text and date, but, you know, the meat of this demo is we can also collect signatures. So I'll just go ahead and do text to signature and submit. This is now, at this point, generating a signed version of our document and saving it back to Salesforce. I'll just make sure that these all load up, and then I will quickly, show that opportunity and where it was saved. And then we'll go on to the next architecture pattern, with Mike Sable. At this point, what's happening behind the scenes here is if I had configured this for write backs, it would be taking my inputs and writing them to Salesforce. We're generating a nice audit trail, so we're we're compliant if you need, compliant signature. And there we go. We have now saved it back to our record. So I'm gonna come back over here and give this a nice refresh and just point out where our signed version of the document has been saved under notes and attachments here with the audit trail appended in the title. I'll give a brief brief look of that when I scroll down here. We have my signature, my inputs, and our Estox audit trail appended. Going far forward, again, we'll we'll save that we won't sign this document every single time, but that is our end to end, S Docs and S sign experience powered by a ScreenFlow with some user inputs. I'm now gonna turn it back over to Mike Sable, and he's gonna talk about our next architecture Great. Thanks, Hannah. So just to kinda close that off, pattern. what's important here isn't just the UI of our product or the Salesforce platform with the screen flows. It's really about the logic and how it's structured in a way that can be reused and communicative back and forth between the two the two platforms. Before we move on from ScreenFlow pattern, though, there's another pattern worth calling out here, and it's something we especially see more with enterprise organizations, and that's Omni Studio. A lot of larger Salesforce implementations are already using Omni Studio to orchestrate more complex guided user experiences across industry specific workflows. And in those environments, document generation really becomes part of a broader interaction framework and not just a stand alone process that's a little more straightforward like we just demoed. Now what's important architecturally is that document generation should fit just cleanly into those orchestrated experiences. And what you didn't see here yet is there's an SDK that S Docs provides that allows document generation to be invoked as part of an Omni Studio driven process, much in the same way we've just seen with ScreenFlow and what we're about to get into with more of the, the record trigger flows and Apex, spoiler alert. The consistency here, though, is what matters because enterprises, they don't wanna separate document generation strategies for every orchestration framework. They still want standardized governance, reusable logic, centralized templates, and just a flat out consistent security model. And that spans down to anything below enterprise level customers as well. These are the common core things that that customers are looking for across the board. So it's especially important, though, in industries where Omni Studio is commonly used. And what we see is financial services, health care, our big vertical public sector who are on GovCloud, where the workflows tend to be highly guided and also highly regulated. So again, we won't go too deep into Omni studio configuration today, but the important takeaway is that the same architectural patterns extend naturally into Omni studio based experiences as well. For our next pattern, we're gonna take a look at record triggered automation, and this is probably the most common pattern that we come across in our day to day. This is where document generation happens automatically based on a business event. So you wanna think about using this when the first and foremost, the trigger is predictable. You don't require any user input, and you really wanna think about consistency and speed. Now a great example of this, the one that we frequently see, and you'll see a demo of here in just a moment, is when an opportunity reaches a certain stage, a proposal, an invoice, whatever stage you're at, the appropriate document gets generated automatically. It may even be distributed automatically as well-being attached to an email or through a signature request. So this is where DocGen really starts to feel like the infrastructure. It just happens as part of a process. And, again, the advantage of a native approach is that you can embed this document generation directly into a flow with out of the box invocable actions. So I'm gonna hand the stage again over to Hannah who's gonna show us what this looks like in in real time. Awesome. Thanks, Mike. So, again, we're gonna be using this same MSA document. I actually would like to start with the flow canvas for this one first just just to kinda talk through, you know, our invocable actions and what this looks like on the back end because there's not a lot to the front end of the demo. That's the the beauty of automation. I'm gonna flip the stage on our opportunity, and our MSA is gonna appear as simple as that. So as we can see, I have this record triggered flow configured. The the entry criteria is where stage is equal to negotiation or review, and we have our s docs invocable action embedded here. All our invocable act these come straight out of our managed package. They are looking for a base record ID, in this case, the triggering opportunity, and then a template ID, which is just our standard MSA that we've been seeing. And that's all there really is to it. As Mike mentioned, we also have invocable actions for the whole entire signature process, so preparing and sealing and then emailing the envelope. So if you wanted to automate the full end to end when the opportunity is set to negotiation review, the email is already packaged up and fired off, you can do that as well. Again for today we're just gonna see that MSA being produced. So without further ado, I'm going to come back to my opportunity here, mark this as negotiation review, and save the record. You will note that we have two standard MSAs down from, my first demo. So what we would expect to see is a third. So as soon as this saves, I will refresh the page, and we should see that standard MSA saved here successfully. So I'll go ahead and give it a refresh. And would you look at that? We have three standard MSAs. I'll briefly preview this one. This looks like our most recent version. It's just gonna look exactly the same as the one I generated in the first part of the last demo. And I apologize I forgot to mention, this invocable action is the same exact invocable action I embedded in the previous ScreenFlow demo as well. So just to add a little bit of color of under the hood there as well. Alright. I think that'll do it. I'm gonna turn it back to Mike to talk about our next pattern. Great. Thanks again, Hannah. So now we're really starting to move from the user driven and into the more system driven automation. So our next pattern, it's necessitated when complexity starts to increase and maybe flow alone isn't always enough, and it's where Apex comes into play. Not as a replacement, but just as another service layer if you wanna look at it this way. So you wanna think about using Apex when you need orchestration across multiple steps. You want a reusable service that multiple processes can call, or you're maybe handling more complex logic or conditions. Helpful way to think about this is flow really excels when you define when something happens. Apex really excels when you wanna define how something happens. In many enterprise architectures, what we see is document generation is wrapped in Apex so that it could be reused consistently across these multiple entry points. Now S Doc supports this model through the SDK again, allowing you to invoke document generation programmatically. What you saw just now in Hannah's demo was the invocable actions, but those are all built on a foundation of method signatures. Still leveraging that native data, native data and security. So, I'm gonna keep this one short. I'm gonna hand it back over to Hannah, who's gonna show us a little bit under the hood of Apex. Great. Thank you, Mike. So as Mike said, all of the generations we've seen so far are we're using our invocable actions, which just basically means that they are flow ready. You can pop them right in. They come out of the managed package. The underlying technology, we allow you to tap in through through our software development kit and method signatures. So we're gonna take the same exact record triggered flow demo, and I just converted it to an Apex version tapping into our method signatures. So we're gonna take a look at that. So I'm gonna open our developer console here very briefly just to show it on screen just to show that I wrote another trigger on opportunity. In this case, in order to not interfere with my other demo, I had to choose a different stage. So we're gonna go with perception analysis, and it's all it's doing is calling, this Apex class that I wrote, which is gonna contain our method signature. So let's take a look at this Apex class very briefly before I go ahead and run the end to end demo. So here's our Apex class. I think the really cool thing about us exposing our our method signatures through our software development kit is you get a lot of flexibility when you tap into things this way to write, the document generation in any execution context you need. So I'll take a second here to just comment on some things I've seen in real life that is the most applicable use of our method signatures. Number one, oftentimes, I see where people build their entire UI, either through Java or maybe a custom LWC, and they just need S Docs to be a part of some larger end user workflow process. So the SDK allows you to kind of, like, come in the back end and plug in our document generation behind the scenes, especially when you're kind of facilitating the experience with a very custom built UI. Another one, mentioning execution context is this allows for scalability as well. The world's kind of your oyster in terms of how you wanna wrap this and what execution context and how. And as we all may be aware, we're since we're a 100% native app, we are beholden to Salesforce platform limitations. So this the method signatures give you a ton of flexibility to kind of, write your own code and, you know, work within the limitations of some of the Salesforce platform limitations like, CPU timeouts, SOQL 101, and file size and things like that. So back to this Apex class, the meat of it is really our FStox document, SDK. This is the same exact, underlying technology we saw in the invocables, but this time exposed in Apex. Again, like we saw with the invocables, it's taking a template ID and a base record ID, in this case, opportunity. And then we also have some generation options that are just setting sharing settings, and things like that. So, yeah, that that is the overall architecture of this simple demo. Again, I I often see this exposed with much larger, like, enterprise level customizations or large volumes of document gen. But we'll go ahead and mark this as perception analysis and save it, and we should see our fourth standard MSA generate down there once this goes ahead and saves. So I'll give it a little refresh just to make sure that everyone sees that there's now four here. And, you know, I'll pop it on the screen very briefly, but, again, we've seen this document four times now. It's the same exact thing. It was now produced via Apex instead of invocables and flows. Great. I'm gonna turn it back over to Mike, and we're gonna bring it home with the last, architecture pattern here and demo. Great. Thanks again, Hannah. So now we're getting into patterns that really enable true reuse and scalability. So at scale and you continue to scale, two additional patterns really become important. That's gonna be the event driven and asynchronous processing. Now when it comes to platform events, this allows you to decouple the request from the processing itself. So instead of generating a document inside a transaction, you publish that event and it handles things downstream. Now this is especially useful for when you don't wanna slow down the user. Hannah just mentioned some of the limitations that we see on the platform itself. Those are hard to get around sometimes, but you can do this with platform events to kinda circumnavigate that. And maybe you're coordinating across systems and you get information coming in from various various, areas, maybe experience cloud, and you have, guest users coming in and submitting information. But the next level of this is asynchronous and batch processing in particular. And this comes into play, obviously, when you're dealing with large volumes. So using that kind of framework of a lot of information coming in from a specific source, you may wanna hold off and generate a bunch of documents at one point, instead of doing them synchronously one at a time. Right? So the key idea here though is a separation of concerns. It's the triggering versus the processing itself. And because S Docs operates natively, this is another one of those things that can participate in these patterns without introducing external dependencies, and it becomes much more important again for some of those those governor limits that we talked about at Salesforce, when you really wanna have performance, increased. Again, I'm gonna keep this part short on my talk track. Hannah's got a pretty compelling look at this, and I'll hand it over to her for for that. Great. Thanks, Mike. Yes. So let's go ahead and take a look at our final demo here at least with the standard MSA. I have so for this scenario, we're gonna have to use our imaginations a little bit. The the mock scenario that I I spun up here is think about if we have an external system for invoicing and maybe that external system is going to publish some event to our Salesforce platform and communicate that this opportunity has been invoiced and then maybe we need to run a bunch of different actions from that event publishing, one of which being S Docs Generation. So I don't have an external system connected to the sandbox, so we're gonna actually just force publish the event, via the dev console. But, again, just keep in mind all I'm doing is publishing this event, and I'm just grabbing the opportunity ID from the opportunity that we've been reusing over and over for this demo. And the event that I created, in Salesforce is it has a placeholder for that opportunity ID. So that's why we're going ahead and doing that. So I'm gonna go ahead and execute this. And, again, the beauty of automation, our MSA ready platform event triggered flow is gonna pick up on this event once it's published, and we've already seen this over and over again. Our invocable is just embedded in this flow, and it should go ahead and produce our MSA. Now I will say here for this demo, I did choose to use the flow canvas because I think it's really easily digestible. But if anyone on the call is a developer, you can probably imagine how, you could also write your own platform event Apex custom Apex and use our method signatures like the last demo we saw as well. So without further ado, I'm gonna go ahead and execute this. And now the event should be publishing, that flow should be picking up the event publishing, and we should be able to come back here. And we have four MSAs right now, and I will go ahead and refresh. And we now have five. I'm not gonna go ahead and show it again. I think we've seen the standard MSA enough, but, I think Mike needs to to speak a little bit on batching and asynchronous processing, and then we'll go ahead and do that last demo as well. So I'm gonna turn it back to Mike. Yeah. For sure. Yeah. So as Hannah mentioned, batch processing really comes into play when you're dealing with the volume. Right? Great example. You have an experience cloud site set up and, you have guest users coming in submitting a bunch of information. You don't wanna do those one at a time. Right? You wanna collect that information, bring it into Salesforce, and then trigger a job later down the line, whether that's manually or programmatically, and process that entire batch of documents at once. So, rather than just talk about it, I can hand it back over to Hannah who can show us that pattern, in real life, how it would work in our product. Great. Okay. Final demo here today. We're gonna take a brief look. We're actually gonna stray away from the standard MSA if anyone's tired of seeing that document at this point and and use a different one. So, today, I have set up, basically a ScreenFlow that ingest multiple records. So in this case, we're using contacts from a list view and will produce multiple Estox documents. So before I get into the the show and tell of this demo, I just wanna comment very briefly. We talked about some of the Salesforce platform limitations and circumventing them. It's very important to do that when it comes to batch batch processing. So the way Estox use manages batch batch processing, sorry, is using asynchronous document generation. So basically, we offload all of these jobs to the Apex job queue. And when Salesforce has the power to go ahead and and process those jobs, they are completed. This helps us get around things like if we have hundreds of records to produce documents for at once, we're not running into things like SOQL one zero one, CPU timeout, Apex heap, etcetera. So without further ado, I will show, you know, the end to end of that generation, and then we'll come back and we'll look at the flow canvas very briefly. So I'm gonna choose a couple contacts here to do document generation for all in one go. Over here, I have another button called generate ad stocks. This is just a button to auto launch my ScreenFlow. I'm gonna go ahead and click that. I have a screen configured that's asking me which, templates I'd like to produce. I'll go ahead and generate a birthday coupon and a welcome letter for all of those contexts I just chose. This time not the standard MSA. And then like I said here, at this point, we're inserting those Apex jobs into the job queue. So this demo differs a little from the rest of them where that spinner previously was the documents being generated in the background. That spinner this time was the jobs being inserted into the queue. I've added some language here just to show that our our batch document generation action outputs the Apex job ID. So if you wanna go right to monitoring to to see what the status of that is, you can do so. Thankfully, in this this org, I don't have very many competing resources. So now that I'm I've talked about all of it, hopefully, Carol White's, document should be generated. So let's go ahead and take a look at her record. And maybe not quite yet, so we'll give it a refresh here. But, basically, I'm looking to see that that welcome letter and birthday coupon would be under this generated documents, and base those will appear here once, that Apex job is complete. When I tested this earlier, it didn't take too long. So there they are now. Let's take a brief look. Here's the birthday coupon, and it has Carol's name on it. And here's the welcome letter, with, I think, addressed to Carol and some other information mapped from the account. And if I come back here, I'm sure if we go to Vanessa, we can see Vanessa's welcome letter and birthday coupon addressed specifically to Vanessa. So, just a quick demonstration of how we can, you know, generate multiple documents for multiple records en masse. I will also briefly show the flow canvas for this one. For all our developers in the audience, this same, generate in batch Apex invocable is available via our method signatures to tap into directly as well. The difference here compared to the other invocables is that instead of taking a single base record and a single template ID, it's taking a collection variable of either. And then we have some other fun things here that allow you to kinda control, the batch size. And we also allow for the ability if I wanted to combine all of those birthday coupons into one big file with multiple birthday coupons, maybe that I'd wanna send to the printer and print out, we can combine all of the documents generated from our batch action into one file as well. I think that that does it on all my demos today. So thank you so much for kind of tuning in to, Estox and seeing things live. I'm gonna turn it back over to Mike to kinda bring us home here. Hey. Thank you, Hannah. So that was our four core patterns that we had planned to discuss today, but I did wanna bring up kind of a bonus pattern. And this is one of the emerging patterns that we're starting to see on the rise, and it's the shift towards headless or API driven workflow experiences. So as we discussed today, traditional document generation workflows have been closely tied to a Salesforce interaction, whether it's clicking a button, manually or programmatically launching a flow, triggering automation from a record update. But increasingly, organizations are designing workflows where the user experience itself may live outside of Salesforce. And this is only accelerating more now with the launch of headless three sixty, in the recent recent months here. So this could be anything from the various AI services. You have Cloud, ChatGPT, maybe Copilot. That's one we hear a lot about. You have customer portals, maybe partner experiences, experience cloud itself, custom web applications, really though this broader composable set of digital experiences. But Salesforce still acts as the orchestration and data layer. The interaction layer becomes more distributed at that point. And what's really interesting about all of the architectural principles we've discussed today is they still apply. You still, as a user, want reusable services, the centralized governance, standardized invocation patterns, and the consistent business logic. The difference here is simply where the request originates. So this is where API first and headless capabilities come into the spotlight. Through the S Docs SDK again, headless and headless three sixty capabilities, document generation can participate in these externalized workflows programmatically, not just through the Salesforce UI interactions anymore. So the same underlying document generation service can support Salesforce native automation, event driven processing, and external digital experiences all simultaneously. Now we actually see this as part of a broader industry shift towards more composable enterprise architectures. Organizations, they all want the flexibility to evolve user experiences independently from the underlying business service itself, and document generation is increasingly becoming one of those reusable services. Now regardless of whether your workflows are user driven, event driven, or increasingly headless, we see scrolling here on the screen. The long term success of these architectures really comes down to governance and maintainability. So let's bring it all together. In practice, you rarely use just one of these patterns. A typical enterprise or any size business architecture might look like a ScreenFlow or maybe Omni for some guided input, Flow for event triggers. You have Apex for more advanced orchestration, platform events, async scaling, maybe headless three sixty or starting to dip your toes in the water on some external interfacing as well. But the key is is that all of these are invoking the same underlying document service, and that's what really gives you that consistency and scalability and the resiliency of having a, a stand up architecture. So the final piece of this is governance. And if you don't think about this upfront or design for it upfront, I can assure you the complexity will always creep back in and cause a headache down the road. So some key points here that I just wanna put note to, make sure you're centralizing templates and branding, making sure that there's no no clutter, or versioning problems going on where your users might be confused about which template's the the final or the most current template. You wanna make sure you're standardizing in vocation methods. So as I mentioned earlier, you don't have all these different, actions doing similar things that are slightly different or modified. Implement logging and monitoring. We didn't talk too much about this today, but if you have an efficient way to diagnose and troubleshoot, that's gonna save you a lot of trouble as well, in getting things up and running smoothly. And then, of course, design for testing and change management. Again, this is a, an end user courtesy. You wanna make sure that all of your end users are prepared for any changes that are coming down the road. But in reality, a well architected system should make it really easy to answer three simple questions. What's generating this document? What logic is applied? And what happens when something fails? If you take care of these three things, you're gonna be able to keep your system maintainable for a very long time. So everything we discussed today is really truly about leveraging the Salesforce platform to its fullest. Now, again, if I could, promo our product a little bit more here, solutions like ours, like S Docs, they are designed to fit into this model. And you saw through some of the demos that Hannah gave today, we really do strive to make sure that it's integrated with the Salesforce platform. Almost feels like you're using Salesforce itself, so there's not a lot of disjointed experiences happening. But, ultimately, it's operating native natively. It supports multiple invocation patterns, and it's really enabling that service oriented approach to document generation. But the most important takeaway, again, it really isn't the tool. It's really the architecture that it all supports. So if you wanna take away three things from today, I would say number one, treat your document generation as a service, not an action. Choose the right invocation pattern for the right job. Again, as I said earlier, you don't wanna use a hammer when you need a screwdriver, and then, of course, design for reuse and scale right from the beginning. That's gonna be something that'll save you a ton of time down the road, and it's gonna make document generation much more enjoyable for you and your end users in your org. Great. So with that, I think maybe I'll hand it back over to Tim now. I think we had some questions come in, so I'll let you, moderate those questions, and we'll answer them the best we can. We certainly did, guys. That was a brilliant demo. We do have a lot of questions, so Marissa had a question saying, how does S Docs handle integration with third party managed packages like Hive, where standard objects or components are locked? Is it possible to scale our document generation without modifying the package itself? You want me to take that one, Mike? Yeah. Yeah. You can go ahead and take that one, Yeah. I guess. Thank you. gonna say say a very broad statement. We integrate with them pretty pretty well. It's just a matter since we're a 100% native, it comes down to permissioning and sharing settings. So we operate we can modify S Docs to work on standard and custom objects and custom objects as a part of managed packages. The only thing I've ever seen when it comes to those managed packages is just making sure the user generating the document has all of the things that allow them to access those objects, and then S Docs works flawlessly with it. Beautiful. Beautiful. So because you had native as well, you get to sort of benefit from the Salesforce, you know, out of the box security features as well, which which will give you access to to everything you need to do. As you're saying. Yeah. No. I. like that. That's brilliant. And there was another question also. Will the recording be shared? Yes. It will. There was a question that came in for Grace that was answered saying, is S Docs part of Salesforce or another application integrated into Salesforce? Again, S Docs is 100% native managed package available on the agent ex on the agent exchange, also known as AppExchange, not by the Salesforce's own product suite. We had a question come in from Elle. Why would an enterprise client leverage a paid app for DocGen if they're already using Omni Studio, and it can and that can be used for the same purpose? Yeah. Mike, I might lean on you. for the pros and cons of this one. Yeah. No. That's a great quest question, and I I think it ultimately comes down to flexibility. What we've seen, at least in our experience, is, there's still a lot of, like, foundational pieces that are being built, at least from, like, the customer perspective, standing up Omni Studio flows in their orgs. Where we come in is is actually whether, they might be using us already in a lot of cases, and they wanna integrate us into their Omni Studio flow rather than kind of upending everything they've built already for document generation. So they wanna utilize the same templates and just kind of insert the generation piece into their Omni Studio, workflows. Yep. Oh, I did not mean to interrupt. I was just gonna add on. We didn't show it today in today's demos, but we do allow for our documents to be edited live on platform if they're PDF generated. And we can embed that live editor right into Omni as well as ScreenFlow. And that's something I'm aware that the OmniDocGen does not does not support. So, like, produce document, surface document, and live edit right in line and then, you know, continue your processing. So super super feature rich, a lot more sort of flexible than the than the built in, Omni Studio, doc gen tool. I like that. That's that's that's good. The next question came from Edgar. Does esignature request support other languages? Yeah. Yeah. Absolutely. The short answer to that one is yes. We Our templates and our entire UI, we we have a built in translator tool so you can change the UI to another language. You can produce templates in any language you like. Fantastic. Yeah. For furthermore, I can add to that. You can actually decide that with logic built into Salesforce. If you have, like, locale information or specific user, or, like a contact country, preferred language. Any of those fields could be used to dictate which which, language is used in the interface and the templates itself. Yeah. Good ad, Mike. Thank you. Brilliant. That's very handy. Next one coming in from Lupo. How does S Docs handle Salesforce files and embedded image compared to native document builder? And a follow-up question, How well does S Docs integrate with work orders and service appointments in field service? You You want me to take that one you can add on, Mike? Was the first question was how sorry. Can you repeat the first one, Tim? I got hung up. on the second one. No. No. Absolutely. Absolutely. So the first question was how does S Docs handle Salesforce files and embedded images compared to native document builder? Okay. I can answer for how ASKdocs handles it. Am I I'm not super familiar with the native, Salesforce, but, basically, all our documents produced, if they're a PDF format, are content, documents and files. So we leverage all of Salesforce native, you know, file versioning, and linking back to base records through content document links and things. So if you're familiar with that and and file sharing, we're a 100% native in that sense. And then embedded images, we can handle those in a lot of different ways. If they're Salesforce, static resources, we can embed them. We can grab anything publicly. We can build an image from a URL. It's kind of a very open ended question, so I might leave it at that. I don't know, Mike, if you wanna add anything to talk about how we compare to native Salesforce, and then maybe we can go over the service appointments and work orders question. I think you kinda covered everything there. I I would like to dig into the the latter question. Sure. No no worries. I'll keep that one short and simple. We integrate just fine with work orders and service appointments. We've set up best docs on both of those objects. And, Mike, I'll toss it to you if you wanna elaborate more than that, Yeah. but we. I know that's, when it's anything specific to, like, like, a specific cloud service, we we tend to I mean, it's a regular practice of us to update with the APIs that Salesforce rolls out. So it's usually just a matter of that. Any kind of custom object or standard objects that come out of the box, we we handle pretty eloquently. So I think that's all I'll add to it. Beautiful. One of the benefits of being fully native, Love it. Yep. Alright. Another question from Grace. Can you create dynamic docs that bring in variable data from the record depending on certain criteria? Absolutely. I actually will admit that the first demo I showed where we picked the terms and conditions, that was just a way of me to show some user interaction. If you were onboarding with us stocks and you had that use case, I would even suggest taking it a step further and saying, is there locale information on this record that can drive the terms and conditions without having user choice? You know, like, is it already is the account based in North America? Make me an MSA that says North America. Absolutely. Yeah. We were just extrapolating out for demo sake, but we can do that for sure. That makes a lot of sense. We didn't, I I think we didn't take a look under the hood of the actual template too much today, but we do have conditional logic building built into the template builder. That happens right on Salesforce as well. Little forward looking statement here, so just keep this in mind. Things may shift. But, we are investing some some time into kind of reinventing that template editor experience. Much more declarative conditional logic building is on the way. We're we're shooting for summer for that as well. So keep your eyes peeled for that. Really? Love the little forward looking statement, excitement. Something to look forward to. That's good. Question from Mino. So we we already have our stocks installed. Can we try the invocable actions in our sandbox to try it out? Alright. Yes. Yeah. Yeah. Absolutely. They should. I guess I could've gotten to it a little more on the demo, but you should be able to go, like, search up Apex in your flow, and they should be listed all there for you. Your sandbox should have an unfettered access. If you run into any issues, I would say reach out to support at S Docs. Sometimes they're behind, like, a flag wall bending your your contract model. But if you're looking to trial things, we usually love to open that up so you can get your hands on stuff. So just reach out if you're having any issues. Yep. We've also just launched our new knowledge base, as of last week. It's kind of like a dark launch right now. But if you wanna go to help.sdocs.com, I'll post it in the chat too so everybody can go look at it. There is some updated documentation of how to use the, invocable actions in particular, but pretty extensive documentation if you need it. Again, you can always reach out to us or support if you need any help getting those stood up. Wonderful. Beautiful. I think. Well, there there there you go. That'll be good to to jump in and get those tested if you've if you've got your stocks installed already. Brilliant. Question from LA Martinez. Can you create a quote format in our stocks? Yes. Of course. I should've I should've showed it. Yeah. Absolutely is the short answer. We support related lists and quoting. We even right on our our we have a template library, on our website. So if you have, like, a free version of S Docs, one of the templates you can download is a quote. It's very standard, of course. But if you wanted to see that in action, I would highly recommend you go and check that out. Makes sense. Makes sense. Question from Elle. What does high level pricing look like and or how does it compare with competitors? I can take that. legs Yeah. yeah. I will I won't get into specifics on the call, other than, we are competitive priced. You're competitively priced with our competitors. We do offer, seat based models as well as dock based, so consumption models. And then those can just kind of adjust depending on your usage. And, I think we offer, obviously, discounts for higher usage rates, but it really is just a matter of how much you wanna use it and how many people you want to use our product. I think, don't quote me on this, but I believe the entry level point for seat based models is is $20 per user per month. But, again, the best thing to do here would be to reach out to sales, our sales team and and really get some information on that. And I can do that. The easiest way would be to scan that QR you got up there and request the demo and get Exactly. Yeah. That's gonna route you right through sales. touch. Beautiful. Beautiful. We've got a couple more questions here. So question from Lorraine. Is s docs esign functionality doc gen sorry. Sorry. Let me reread that. Is S Doc's esign functionality doc gen driven driven off it? Hang on. Sorry. Is S Doc's esign functionality doc gen driven, or is it an S Doc's development? I think they're asking if it's, like, native or not is my maybe. Mhmm. And I think the short answer to that would be, the assigned portion that you saw today is also our proprietary solution. It's a 100% native, but it is an S Docs. We call it assigned solution that you can, you know, scan to request a demo and you can purchase licensing through us for. Yeah. That's, that's technically delivered as another managed package. We we refer to it as an extension package of the S Docs product. It is not currently publicly listed on the AppExchange or, sorry, the AgentExchange now, but it is, all past security review and everything. It's, it's if you if you're interested in it, it's one of those things that we add on. It's, it's kind of a, core functionality rather than, like, a separate product itself. We just refer to it as s sign. Gotcha. Okay. And there's a follow-up, actually, that that ties in perfectly to that to that last question. If we have 30 document generation licenses but only need five s sign licenses, is that possible? Absolutely. Yes. That's a short answer. there. That's good. Pro pricing that's as flexible as the product. I like it. Alright. Is it possible that when a user signs an s doc, it automatically updates fields in a particular s object and related s object? I think you did briefly touch on that, Hannah. Yeah. I didn't show it, but, yes. The short answer is absolutely, especially those free text fields. You basically just map back where you want them to write back that information, and that is a part of our assigned product for sure. Fantastic. How many s docs can be generated using a batch option using the Apex action? Is there a cap as to the number of s docs per batch? It's a really nuanced question. Again, that's where we kinda get into that, like, architecture discussion. So it's a great question to ask for this webinar. It depends on how complicated your document is, how many SOQL queries you're doing inside said document, how big those documents are. That's why we give you the flexibility to choose the batch size. It's really something that you need to kind of hone in for your specific use case. At some point, you will hit Salesforce platform limitations, but that's where this whole conversation comes in with, like, you know, maybe we switch our batch size, maybe we optimize our queries elsewhere. You know, it it's very nuanced, but we've seen. maybe I'll turn it over to Mike to talk about, like, the level of some higher upper volume limits we've seen at the enterprise level. But, you know, it comes down to architecture to kinda circumnavigate some of that, but it it's a lot is what I'll say. Mike, I don't know if you wanna add any more detail and color around, like, Yeah. maybe some of really is a hard question to answer. It really just depends on on the content of your document. I think we've seen everything from, hundreds of documents. If there's, like, a lot of even rich images in it, that kind of up the level of each PDF that's gonna be processed. There's also jobs I've seen where thousands of documents are created, and it's basically just text based stuff. But I think the the one variable is, it's it's more so around, like, the richness of the content itself. I think when you're talking about the data coming into those from Salesforce, that's actually a pretty high high volume, if that makes sense. So, like, the the number of fields that you're pulling into any given document isn't really one of those things that impacts it as much. I think the thing we see more often is, again, like like, images are the one thing I always think about when it comes to, like, somebody running into limits and and processing with batch in particular. That's where we typically see where you have to split up the batch sizes to be a little bit smaller so you can kinda get those through a little more efficiently. I don't know if that helped, but that's that's my take on it. I think the short answer is it's very use case dependent, but you can, you know, massage things with your architecture to get get where you need in most cases. Yeah. Yeah. Yeah. I like it. Good answer for, like you said, very, very, nuanced. That that was good. Very insightful. We have two more questions. Just a reminder to everybody. If you got any questions, pop them in the q and a. We we may have time to answer some additional questions on the call. Question from Sherry. How to preselect multi multi templates combined into one document base based on what products are in the quote. So. I was just, like, digesting the question for a second. I just wanna make sure I'm interpreting that correctly. It sounds like they're asking how how to preselect multiple, like, products to include in a quote that they wanna produce. Is that your interpretation of it? The the way I understand is it can is it possible to slash how is it how are you able to select multiple templates to combine into a single output document is the way that I'm reading. Yeah. Got. it. Yeah. Yeah. We have a template type called component template. I didn't show that on today's call, but, basically, it's a reusable template. So template as a component, and then you can combine multiple components for reuse inside of, like, a larger parent document. Usually, a picture speaks a thousand words for that one. So if you would love to see a demo of that, you could absolutely scan that QR code, and we could talk about it more. Good call. Good call. We have had a few more questions coming. So so, any plans to make the PDF I I think you just alluded to this mic. Yes. Any plans to make the PDF template editor more user friendly? Any plans for better support for DocX templates? Yes. I'll start. The, the first one, the template editor, yes. This is a a big area of focus for us, coming out of last year, and and we're rolling it through the summer of this year. So we're looking to launch in July. We actually have a very, very much user friendly experience that we've developed. The the key here is, again, this is something I said in the in the, talk track today for the webinar. We really do try to grow our product alongside Salesforce and and integrate pretty, exclusively with them. Part of that, obviously, one of Salesforce's missions is, you know, clicks not code, making things more declarative, whether it's Flow Builder or any other, any other thing that falls under that that topic. So what we've done one of our biggest differentiators that we've identified is actually our on platform template editor. But we realized that it is kind of a pain sometimes. You if you wanna do some complex stuff right now, you have to get into some source code editing. Sometimes you either don't have the knowledge or the the technical resources on hand to do HTML or CSS editing or even build logic within those, the SOQL queries within the template itself. So what we did was we actually took a step back and we reinvented all of those complex things, put them into much more declarative interfaces, and, are planning on delivering this, like I said, in in July year. So, again, if you're interested, scan that QR code and in your message to us, just mention that you're interested in the PDF template editor. I'd be happy to jump on a call, show you kind of a early days demo. It is working product at this point. It's just not ready to be delivered yet. But I'd love to get some feedback on it and and have conversations around that as well. As for Docx, we have made some advancements on that. Salesforce, again, this is another thing that falls in the vein of just improving with Salesforce itself. They recently as of last year, they launched a new compression functionality. And what we did was, we we rebuilt our docx and all of our x file functionality, so all the MS MSX file formats. PowerPoint, Excel are also included. We built that on the new compression functionality. So it's a much more elegant way of handling it. Previously, we would handle the the zipping and decompressing of all that, which was very, very clunky, admittedly. So we basically reinvented that from the ground up. You didn't see it today, but those LWCs that Hannah was generating documents on are also now compatible with docx format and the other Microsoft file formats as well. So, again, another topic we could discuss, if you wanna reach out through that QR code, we'd we'd be happy to look at your use case and figure out how we can support that best. Love. it. Love it. There's one more question. It may be, I suspect, may need to be go through the QR code and have a bit of a chat, but I'll quickly run through it from Ashley. We have a lot of customers who still wish to sign documents manually, but then need to upload and then have a second person he signed. The S Docs e signature seems to now not allow someone to sign this document without signing in. Is there another solution? Are. we gonna get off in fourteen seconds? I'd I'd be happy to answer it. I'm just looking at the time. Are are we gonna auto get shut off? I I don't think so. I think we go into. overage. Okay. Cool. Yeah. We're all good. Alright. I might, like, I might, lean on you a little bit, but I I'm kinda thinking in my head the first thing that jumps up is that sign in person. I know she's probably more manually asking for a specifically wet signature, but I will speak about her sign in person very briefly. So you can set up your first signer to be signed in person. So that means if you have a tablet in your hands, you could kinda present the the tablet to them and they could do the signature, and then the next one can be routed through email. That is supported through our product. As far as wet signature, I could think of some possible workarounds, but, yes, it's not really we don't really do document upload. So there there's some things that we could probably manage in Salesforce. I'm putting on my Salesforce architecture hat, not my S Docs hat right now. But, you know, I I I won't go into a full solutioning thought. You don't need to hear. my my my insight thoughts on that right now. I don't know if you wanna add anything, Mike. Yeah. Just with that workflow, I know it's like a sign, countersign situation, so it makes sense for the the countersigner who may be an internal party to sign second. If possible, I would say have that person sign first and then the external party print and wet sign if that's the case. The the caveat to printing and signing it manually, if that if that is indeed what we're asking about here is you actually break the audit trail at that point. So while it is a wet signature, you do kinda lose the proof behind the, the legality of the signature itself. And at that point, kind of the responsibility or the onus of proving that it's a legitimate signature falls on the, the sender. And and we like to kinda keep that responsibility with our our software and our product. So, I would just advise against it, but if it is that sign in person workflow, we do support that a 100%, and that's a digital signature still. And, you would still preserve that audit trail and those those, those proof points along the way. Good call. Good call. Actually, maybe there's a there's a discussion a further discussion to be had if you wanted to scan that QR code and and reach out to the team to sort of discuss, some options where you're sort of protecting the legality of that signature, as Mike was saying, while also supporting a a similar workflow. Yeah. Team, that was absolutely brilliant. It was really good to see it all sort of in action. We appreciate your time. Thank you everybody also for for attending. I'm I'm confident highly confident this is a super beneficial session for everybody. Was there anything else either of you wanted to say before we wrap up? Thank. you for having us. Yeah. Thank you, so much. thank you. was a a pleasure to be here today, and thanks to everybody on the line who showed up, whether it was your evening, your morning, or your lunch break. We really do appreciate it. No. Absolutely. This is this is we really appreciate you guys coming on and and sort of showing us what you got. This was this was really, really good. Brilliant. And with that, everybody, thank you very much. And that you will receive, I believe, an email with the link to the recording, within the next sort of day or two, I believe. Otherwise, we thank you very much again for for attending, and we'll leave you to it. Have a good rest of your day, everyone. Alright. Thank you. Bye.