Implement a Scalable Incident Creation and Notification Process | Automate This!

Use case: Streamline incident capture and communication process

Working for an identity management company made me realize how important it is to keep customers updated about different incidents, outages, and system maintenance. It’s essential to not only let customers know what’s happening in a timely manner but also provide complete and accurate information. Furthermore, it’s crucial to capture all the relevant information for the purposes of internal audit and service reporting. This way, leadership can have complete information that can further be used in analytics and reporting when it comes to resources organization and yearly planning. Having a streamlined and easily upgradeable process to capture this information is absolutely crucial in these situations.

Manual process as a default solution

When the support team first started using Trust records to track incidents and maintenance schedules, they followed a manual process that was pretty time consuming. They would go to the Trust object and click Create New. They would have to select the record type and then populate fields on the record create page, going through the tedious process of completing text fields and choosing values from numerous picklists while paying attention if all fields were relevant to the creation process. This process frequently led to errors in the values that were entered, typos in text fields, or important information missing.

Interim solution with a screen flow

With the introduction of screen flows, we decided to try to automate the creation of Trust records as much as possible. We built a screen flow with dozens of screens trying to capture all the information that was relevant while making decisions based on the entered value. As the process became more complex, we had to add more Decision elements and Assignments, making the automation more complex as well. This new process was slightly better than the manual record creation since it ensured that necessary data will be populated. Screen flows also simplified the training process for new agents and guidance on how to create Trust records. It also enabled us to create multiple conditional logical processes for different types of Trust records and prepopulated some of the fields.

This flow, however, had too many steps and required so many clicks that even though the process was automated, the user experience (UX) for support agents was not improved much. Maintaining this flow and adding new logic with new fields became such a time-consuming task that everyone dreaded enhancing the flow. While we moved from a manual to automated process that helped with reducing data entry errors and ensuring all required fields are filled out accurately, based on user feedback and measuring the time needed to create a Trust record and notify customers, we didn’t notice the expected impact on process efficiency.

Final solution: Dynamic Forms in screen flows

With the exciting news coming from the Flow team that Dynamic Forms for Flow is going GA in Winter ’23, we decided to revamp the screen flow used for Trust record creation. The main goal was to increase efficiency and streamline the process, lowering the number of screen elements and, with that, lowering the number of clicks the user must make to create a record. Dynamic Forms for Flow provided a flexible and responsive user interface (UI) based on specific criteria, ensuring the agent sees only relevant fields and sections. Thanks to conditional visibility on page components, we tailored screens to show or hide certain fields and options based on the user’s input. This had a significant impact on enhancing the UX and improving efficiency. Agents were presented with a streamlined process and a clean screen displaying all the relevant information at each step of the flow.

To make it easier for agents to access this form, we created a new Lightning App Incident Creation and added a screen flow to its home page. Thanks to this approach, agents have a quick and easy way to start new record creation in situations where every second counts. The creation process starts with asking the agent to define the date and time when the incident or outage happened, and then select a radio button to define what they’re creating.

This is where the magic happens. Depending on the radio button selected, a different section with a set of fields will be displayed. And it all shows up on this same screen! There are no additional clicks needed and no screen or context change. In our example, let’s say the agent is creating a new record for a security incident. This is how this screen will change and look like after they select that radio button:

We notice that the new section called Incident Impact shows up with a set of relevant fields for this type of incident. If the agent decides to create a new record for maintenance type, the screen will have a different section and set of fields.

We can see the power of conditional visibility in the example where impacted audience is selected. If org admins are impacted with the incident, we immediately need to know if it’s impacting all the admins or if there’s a partial impact.

This is how the input screen looks when selecting an impacted audience other than Admin:

However, if admins are part of the impacted audience, we would like to capture additional information so that the change is also reflected on the screen:

Once the agent captures all of the information in the first screen and clicks Next, they will be presented with a second screen showing the summary of all of the information recorded that will be used in record creation. Since this information will be used to display information on the status site, we’re also showing text that will be published once the record is created. This is displayed in the long text area field, and agents can add any information that might be relevant for this specific incident. Since this information is going to be published on the website, we’re allowing formatting directly from this page. We have three different event types, so that means we’ll have three different text templates that are going to be displayed along with gathered information.

Once all of the information is added and confirmed, the agent can click Next and the link for the newly created record will be displayed.

Under the hood of the incident creation screen flow

Here’s how the new flow looks. It’s hard not to notice the improvements made to the previous screen flow.

The magic happens in that first screen where Dynamic Forms for Flow and conditional visibility enables us to have only one screen for capturing information for all three types of records. That’s achieved by adding a separate section for each record and then setting up visibility based on the radio button selection on the initial screen.

To make the record creation process streamlined, we’re also using conditional visibility within the sections, setting up dependency on the value of the field within that section. Based on the established business process, we want to send email notifications to customers only for incidents that have high or critical severity. For incidents with lower severity, we don’t want to even show an email notification possibility to the user creating the record. To achieve that, we set up field visibility based on the value the user chooses in the Severity field on the screen.

However, in case the user is creating an Incident record of a different type, like Outage, we want to always include the possibility to notify the customers. In this situation there’s no conditional visibility setup for the same Email Customers field.

Once all the information is gathered, we follow a similar approach on the screen showing the summary of the information based on the selected record type. We set up conditional visibility for each section so the user sees only the relevant information.

For additional flexibility, we’re also displaying a predefined text template that includes some of the information gathered on the initial screen. This text is shown in the long text area, giving the user the option to add or adjust the text template as needed. To keep this selection simple and easy to change or upgrade, we’re leveraging the power of formulas in flows. In the Assignment element, we assign the value to the long text area field Log value based on the record type selected on the initial screen. Since we want to provide different information and embed different fields, we’re using conditional logic in the formula.

In order to catch any errors that might show up, we’re using the Validation Checker Flow Action created by Eric Smith. This custom flow action provides the opportunity to capture the message and redirect the user to the initial screen while displaying the error message in a user-friendly manner. This way, the user can see what needs to be fixed and proceed with record creation without wasting time trying to determine what went wrong.

We finish this flow with the Create Records element and a screen showing the link for the newly created record.

Once again, we’re using a formula in the flow to be able to create a link for a newly created record and display it in the finishing screen in a user-friendly format.

LEFT({!$Api.Partner_Server_URL_260},
FIND( '/services', {!$Api.Partner_Server_URL_260}))&{!IncidentRecord.Id}

Summary

Even though automation can improve the manual record creation process, adding some specific new features in Flow can turbocharge users’ productivity and help create a scalable solution. Based on everything we learned in this process, here are the main benefits of our approach.

• The new flow has much better adaptability for varied scenarios. Beside incident and outages, we were able to add maintenance tracking too. Despite adding one more use case, the agent always sees only specific details and relevant fields for a given context. This way, we reduce the chance of errors and ensure that the agent can focus on quickly creating a record, avoiding the distraction of numerous irrelevant fields.
• With conditional visibility in Flow, we provided a guided UX for agents creating Trust records. Fields and sections are displayed or hidden based on the user selections or input, which provides clear guidance on the required information at each screen or stage.
• Using Dynamic Forms for Flow, we organized fields in logical sequence, presenting them dynamically as the user progresses through record creation. This way, the user can focus on relevant information without wasting time determining whether the field should be filled—and this improves user efficiency. This approach also ensures that critical information is captured before moving to the next step.
• Simplifying and streamlining the process, we noticed that user engagement and Salesforce adoption increased. Feedback from the agent showed that they are more likely to create Trust records themselves (instead of assigning that task to others in the team) because the process was more intuitive and tailored to their specific process. As a result, we noticed that data quality increased, reporting became more reliable, and we had more accurate record-keeping overall.
• Last but not least, Dynamic Forms for Flow and conditional visibility in screen flows made it easier to make updates to the flow as the support process evolves and new requirements emerge. If additional steps or new fields are needed in the future, they can be seamlessly added to the flow without significant redesign. This scalability ensures that our solution stays effective and aligned with ever-changing business processes and improvements.

Thanks to Dynamic Forms for Flow and conditional visibility in flows, we finally have a robust approach for managing security incidents, outages, and system maintenance announcements.

Resources

• Salesforce Help: Make Flow Screens Dynamic with Conditional Visibility
• Salesforce Admins Blog: 3 Ways to Drive Productivity with Dynamic Forms
• Salesforce Help: Flow Conditional Visibility Considerations
• Trailhead: Screen Flows

Want to see more good stuff? Subscribe to our channel!