Best Practices for Business Analysts: Salesforce Integration Requirements

Salesforce integration projects are becoming ever more frequent as APIs are increasingly more accessible to consume from source systems. This is relevant to business teams because it can enhance functionality significantly and improve their business processes. However, integrations between two or more systems are always complex. 

The role of Business Analysts in software development projects can contribute significantly to ensuring all stakeholders and teams understand the breadth of the implementation at hand. As a Business Analyst, it is important to know how to capture these requirements meaningfully for the business to be confident going forward and for the development team to design and implement the ask with clear expectations.

How should a Business Analyst start to map requirements when an integration is involved?

If User Stories are the accepted format for requirement delivery, the acceptance criteria should always outline “what” is to be achieved and not the “how.” For example, integrating via MuleSoft to receive and display read-only data in a Custom Object should be handled by identifying the following: 

  1. Users that can see the data.
  2. Where the data can be seen.
  3. When the data should be seen. 
  4. Any data retrieval failures and what should happen (i.e., show this error message). 

The technical team must provide all other requirements with respect to API names, data type conversions within MuleSoft, data loading, and performance. Business Analysts can, however, assist with providing a list of fields the business needs, outlining the expected field name, data type, format, restrictions, or any behavior that can be used in a Data Mapping document. 

Always ensure to read through the technical documentation and understand the architecture. This must align with business requirements and serve as a checkpoint if both teams have understood each other.

What else does a Business Analyst need to consider?

Three additional aspects haven’t been mentioned that are needed for the success of an integration project:

  1. A picture is worth a thousand words. UX designs and mockups are sometimes needed if the integration entails a custom flow in Salesforce or if the data received and subsequent behavior are complex. Designs add great value for business and technical teams by making expectations more concrete and less ambiguous.
  2. Request at the earliest opportunity any test data that needs to be created. This can cause delays in project testing plans and releases since integrations involve dependencies on other teams.
  3. Know integration terms like payload, API, synchronous and asynchronous integrations, HTTPs endpoints, REST, etc. This aids in both relaying the business requirements to the technical team and understanding technical requirements that might impact behavior in Salesforce.

Overall, Business Analysts add significant value to integration projects by bringing forth desired business processes and Salesforce knowledge with an understanding of how integrations are architectures, enabling a more comprehensive solution for the teams involved.

It is possible for a Business Analyst to have a “format” on how to tackle an integration project. However, this comes with experience as the nature of integration projects becomes more familiar with time, making it easier to plan and execute documentation for the project needs. 

If you’re interested in BA content, check out our blog, Mastering User Acceptance Testing: A Step-by-step Guide for Business Analysts.

Take a look at our Salesforce AppExchange Apps

Our team of Salesforce experts can help you develop a new AppExchange app from scratch, help your business migrate your existing products to AppExchange, provide support services for the apps developed, and more.

A couple of years ago, we created Tok. A flagship Salesforce app designed to help keep organizations in close contact at all times. Our app was built on Salesforce Chatter, allowing instant messaging, team messaging, and groups to connect within Salesforce. That way, conversations were safe, secure, and archived within your Salesforce instance. Your team never had to leave Salesforce to talk and collaborate. This app was our star project, used internally in daily communication and widely used by other companies. 

With Tok’s success in the market, and as our team grew, so did our internal product development team; we developed more than 13 ready-to-install Appexchange apps with over 1500 downloads.

Here is a list of some of the latest apps designed by our team:

  • Oktana Account Map gives your users a clear view of where their customers are. See your contacts’ location, local time, and even birthday on the account page. With the ability to filter by birthdays, contacts you own, and new contacts this week – you can control how many customers are placed on the map.
  • Oktana Calculator & Currency Converter gives your users access to standard calculations and the ability to convert between 170 different currencies without ever needing to leave your Salesforce org. Leveraging the Alpha Vantage API, this component can be embedded in any Salesforce page.
  • Oktana Calendar can take your team beyond the default Salesforce Calendar component, allowing them to quickly add, edit, delete, and even color-code certain events from within any home page (or app page) in your org. Based on a responsive design, this calendar keeps up with your busy users by sending automated reminders, ensuring they’ll never miss an event. Leverage the Salesforce Calendar to help manage your team’s time more efficiently.
  • Oktana Contact QR quickly generates a QR code to add contacts to your phone easily. You can set the QR code to redirect to the contact record in the org or download it directly, allowing you to choose what fields to include. Leverage this component to make importing contacts easier for you and your team.
  • Oktana Location Map lets you quickly look up a location visually on the map; then, it automatically stores the latitude and longitude in the location record for you. This component even allows users to share their location by grabbing a Google Maps link.
  • Oktana Org Limits Monitor makes it easy to track org usage for developers and admins. They are easily customized to show only what’s important to you. Our developers have experienced losing track of org limits, so they designed a component that can be used anywhere.
  • Oktana RSS Feed brings your favorite news sources right into your org. This mobile-friendly component can be personalized with up to five RSS feeds. And most importantly, the admin retains control by setting the default feed and determining which sources are appropriate to access.
  • If a picture is worth a thousand words, a video is worth a million. The Oktana YouTube component lets you embed your video without any code. Admins can choose whether to embed a specific video by YouTube ID or allow users to search for videos.  Every user has their viewing history stored, making it easier to locate previously watched videos.
  • With the Oktana Credflow component, you can now check financial account applicants’ credit scores or criminal background history in just two steps. No coding or design is required; just build flows directly as desired and obtain near-instant results.

These apps are FREE, and you can fully use these solutions without payment. If you need a custom app for your organization, we can build it for you from scratch. Check out our services.

Mastering User Acceptance Testing: A Step-by-Step Guide for Business Analysts

If your role is accountable for the correct understanding and implementation of requirements, User Acceptance Testing (UAT) might become one of your best friends once the solution is built. In this post, we are exploring the importance of implementing UAT, as well as how to prepare and run it. Let’s dive in!

Once the development and QA phases are completed, User Acceptance Testing should be included in your process prior to release. This ensures that the end users, or the SMEs on their behalf, validate that the experience meets the expectations outlined in the requirements. It will be the moment to show “how” those needs are going to be addressed.

Usually, a Business Analyst (BA) is accountable for leading this activity, which requires careful preparation. Let’s break down the User Acceptance Testing process:

  1. Limit the scope: Be aware of the different paths you will be preparing and take into consideration that non-happy paths should be included to ensure different scenarios are being covered.
  2. Create your document: A spreadsheet could be enough, choosing a tool that you are familiar with will be helpful for you and the collaborating users. Construct a template containing some space for the user information, such as Name, Role, and Date. Second, and in order to organize UAT instructions some of the columns that could be used for the headers are: Step #, Step Description, Expected Result, Actual Result (Pass/Fail), and Feedback. Whereas the rows will contain the actual description of each column.
  3. Break it down into the different processes: Separate each process or scenario. Providing a short introduction about what will be covered, will help the users to understand where it begins, ends, and any nuances involved.  
  4. Delve into each step. At this point, you are probably eager to write down each step, so make sure that before getting started you grasp the end-to-end process. You should perform a walk through the entire process (and probably you will need to revisit it a couple of times) while describing each step and the expected result. Using the test cases built by the QAs could be tempting, but that is not a good practice. Don’t get me wrong, QA engineers do a terrific job while testing the solution, ensuring the quality of the development. However a UAT is not a copy/paste of the test cases, take into consideration that the perspective must be the user’s one (which mostly is non-technical), thus each step should be clear, concise, and avoid jargon. For instance, if the user should enter their credentials rephrase it to make it easy to understand, something like “Fill in the user name and the password field with the following information….” 
  5. Double-check the environment. UAT is an activity performed before a functionality hits production, then an environment such as staging is more appropriate (if you are using Salesforce, a Partial Copy Sandbox is a good choice). At this point, you are making sure that each UAT participant is able to access the environment (for Salesforce double-check that users are created in the sandbox and have the appropriate permissions granted)
  6. Verify data and links. Related to the last point, if the user is expected to interact with several interfaces or fill in some data such as passwords, tokens, IDs, etc.;  that information should be explicitly provided in the related step. Moreover, if an input is unique, that should be mentioned upfront, and an example per participant must be provided. It is a good idea to ask the devs or QA for a set of information and let them know it is going to be used in UAT only.
  7. Select the UAT users (including Subject Matter Experts) to join the activity. Be mindful to include people that will be interacting with the solution, where SMEs take an important role too since that can represent final users too. Once you have confirmation, make sure to copy your template accordingly, so that each person has their own.
  8. Set up the meeting and provide support. Explain the dynamic to the participants. Remember you are not the one executing the UAT, of course, to get started with the activity you can share your screen and use a couple of steps to show how each one should be reviewed and the template completed, but it is a hands-on activity for them. Pro tip: ask your participants to record their screen, if any bugs or questions are raised you will know where to refer.
  9. Bug’s prioritization. If any defect is reported, as a BA you should identify and capture it. Heads-up, UAT is not a space for new requirements, thus before reporting the bug to the team review the scope and the priority if, in fact, it is a bug.
  10. Sign off. Once the bugs have been corrected and retested, you are ready for the sign-off with a fully tested solution on both sides (IT team and SMEs)!

Following these 10 steps, User Acceptance Testing may look like a time-consuming activity, but conducting it as part of the development cycle adds value and assures users will have a seamless experience once the new solution hits production.

If you’re interested in BA content, check out our blog The Strategic Role of the Business Analyst in Salesforce Implementation.

How to make your Salesforce org secure: step by step guide

In our previous blog post, “One way to keep your org secure: Salesforce Health Check” we covered the built-in Salesforce Health Check tool, the benefits of running a health check, and why you and your company need one.

This blog will cover some in-depth steps you can follow as a guide if you are a Salesforce developer or Admin to make your org more secure. That being said, let’s get to it!

Salesforce org secure health check

The Lightning Platform has been migrating from Aura components to Lightning Web Components (LWC) for some years. Even though both are still supported and can coexist on the same page and even share information, Salesforce is focusing on LWC, and we should do the same. 

When you run your Health Check application, you have 3 moving parts involved:

  1. The Salesforce org
  2. The client (LWC)
  3. The backend code (Apex)

 

We have configurations available in Setup > Security, allowing us to configure how the app runs. I recommend turning on the following options: 

  • Require HttpOnly Attribute

Setting the HttpOnly attribute will change how an app communicates with the Salesforce server by increasing the security of each cookie the app sends. Since HttpOnly prevents cookies from being read by JavaScript, the browser can receive the cookie, but it cannot be modified in the browser. 

HttpOnly is an additional flag included in the Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of a client-side script accessing the protected cookie.

  • Enable User Certificates 

This setting allows certificate-based authentication to use PEM-encoded X.509 digital certificates to authenticate individual users to your org.

  • Enable Clickjack Protection

You can set the clickjack protection for a site to one of these levels.

  • Allow framing by any page (no protection).
  • Allow framing by the same origin only (recommended).
  • Don’t allow framing by any page (most protection).

Salesforce Communities have two clickjack protection parts. We recommend that you set both to the same level.

  • Force.com Communities site (set from the Force.com site detail page)
  • Site.com Communities site (set from the Site.com configuration page)
  • Require HTTPS

This setting must be enabled in two locations. 

Enable HSTS for Sites and Communities in Session Settings.

Enable Require Secure Connections (HTTPS) in the community or Salesforce site security settings.

  • Session Timeout

It’s a good idea to set a short timeout period if your org has sensitive information and you want to enforce strong security.

You can set values, including: 

  • Timeout value
  • Force logout on session timeout
  • Disable the timeout warning popup
  • Enable Cross-Site Scripting (XSS) Protection

Enable the XSS protection setting to protect against reflected cross-site scripting attacks. If a reflected cross-site scripting attack is detected, the browser shows a blank page with no content. Without content, scripts cannot be used to inject attacks. 

  • Use the Latest Version of Locker

Lightning Locker provides component isolation and security, allowing code from many sources to execute and interact using safe, standard APIs and event mechanisms. Lightning Locker is enabled for all custom LWCs and automatically updates. If you’re using Aura, check your version for compatibility.

One more thing...

I want to spend more time discussing a feature that helps us run our application even more securely. And I am talking about Salesforce Shield. Salesforce Shield allows you to run your application more securely with some features like encryption and monitoring. It adds an extra layer of confidence, privacy, and security and lets us build a new level of trust, compliance, transparency, and governance.

Salesforce Shields is composed of 3 easy to use point and clicks tools, which are:

  1. Platform Encryption: It is designed to bring us state-of-the-art encryption while we do not lose access to key features such as search, validation rules, etc. It can derive the encryption keys from org-specific data or even import our encryption keys(adding an extra layer of control)
  2. Monitoring Events: We often need to track specific events in our orgs (who accesses a piece of data, how the encryption keys are, who is logging, and from where). Monitoring events is the tool for it allowing us to track and access all these events and more from the API and integrate it with the monitoring tool of our choice(New Relic, Splunk, others)
  3. Audit Trail: Some industries require us to keep track of changes in data. Turning on tracking specific fields and setting up an audit policy, we can store historical values for up to 10 years.

Conclusion

It is essential to consider security while developing apps and maintaining our Salesforce org secure. And even though it might seem complicated (and it is), incorporating the Health Check tool and salesforce shield in our development process will help us to keep our org in a good, healthy state.


You can also watch our on-demand Health Check Assessment webinar by my colleagues Zach and Heather, where they covered 4 simple steps to ensure the health of your Salesforce org. 

One way to keep your org secure: Salesforce Health Check

You got your Salesforce org – a shiny, brightening, brand-new org– ready to keep and maintain the most important information your company has: your customers’ information. Also, you start digging into the AppExchange to get those apps we love to provide a better service to your customer or the people who provide service to them. You could have needed to customize your org so it fitted with your business flow or integrate it with that legacy system which is the most important piece in your selling workflow.

As time passes, as all of us, our orgs get bigger, with more data, apps, customizations, and maybe more integrations. We are happy with all this growth as it means that our business gets bigger with more satisfied customers and more sales – in other words, more money. But it also means that our beloved org may have more security concerns that we need to focus on, and as it gets bigger and bigger, the more difficult to track the issues.

Fortunately, Salesforce provides us with a safety inspector that guides us through reviewing our security flaws and getting them fixed. So let’s understand this tool and why it is so useful to any company using Salesforce.

How does the Salesforce Health Check work?

I am not talking about Homer Simpson (we all know that if he is capable of securing a power plant, he would be an excellent Salesforce Admin). 

power plant health check homero
Source: miro.medium.com

I am talking about the Health Check tool. This automated tool lets us review in a dashboard all the issues our org has and guides us through the process of fixing them.

First, you have to be a System Administrator and go to:

Setup > Health Check > Wait a few seconds (I do not suggest going for a coffee yet)

Finally, after that wait, you will see a screen similar to this one:

On this page, you will see an overall score calculated by a Salesforce proprietary algorithm. The higher this number, the better.

Below, you’ll find the issues classified as High Risk, Medium-Risk, Low-Risk, and Informational.

For each issue, Salesforce will provide a description with the classification (critical, compliance, etc.) and either a way to fix it or informational links about how to fix it. 

With all this information, you can fix Security Issues in your org more efficiently.

Watch our on-demand webinar and learn how you can improve the overall performance of your Salesforce Org by doing an Org Health Assessment

Benefits of doing a Salesforce Health Check

Optimal System Performance

A health check evaluates your Salesforce instance’s performance and identifies any bottlenecks or areas of inefficiency. Addressing these issues ensures your system operates smoothly and responds promptly to user interactions.

Data Integrity and Quality

Review the quality and accuracy of the data stored in your Salesforce system. You can maintain reliable data supporting informed decision-making by identifying and rectifying inconsistencies, duplicates, and inaccuracies.

Security and Compliance

Addressing identified security and compliance issues during a health check is crucial to maintaining the integrity of your Salesforce instance. By proactively identifying vulnerabilities and ensuring compliance, you protect sensitive data, preserve customer trust, and mitigate legal and financial risks.

When do you need to perform a Salesforce Org Health Assessment?

  • Encounter errors or performance issues that hinder your operations and revenue
  • Looking for a seamless transition from Classic to Lightning
  • Require assistance with meeting new security requirements or ensuring proper user setup
  • Need a comprehensive diagnosis to determine the actual state of your Salesforce platform

As your business continues to evolve, your Salesforce org should evolve too; running a Health Check is one way to improve your Salesforce org health. Still, you can also run the Salesforce Optimizer, build an Adoption Dashboard, and switching to the Salesforce Lightning experience will help you increase productivity and efficiency, improving the overall performance of your org.

Make sure you run a Health Check at the proper time and the proper way. To learn more about how to keep your Salesforce org healthy, register for our webinar

Harnessing the Power of ChatGPT and Salesforce

Boosting Sales and Customer Experience

In today’s highly competitive business landscape, companies constantly seek innovative ways to enhance their sales processes and provide exceptional customer experiences. Two powerful tools that have gained immense popularity in recent years are ChatGPT and Salesforce. ChatGPT, an AI-based language model, and Salesforce, a robust customer relationship management (CRM) platform, can work synergistically to revolutionize sales and take customer interactions to the next level. In this blog post, we will explore the benefits of integrating ChatGPT with Salesforce and delve into the various use cases that can maximize your sales efforts.

Personalized Customer Interactions:

One of the key advantages of combining ChatGPT and Salesforce is the ability to deliver highly personalized customer interactions. By integrating ChatGPT with Salesforce’s customer data, you can access detailed information about each customer, including their purchase history, preferences, and behavior patterns. This valuable data empowers your chatbots to provide tailored recommendations, answer queries, and offer relevant products or services. The result is a seamless, personalized customer experience that fosters trust and enhances satisfaction.

24/7 Availability:

Salesforce-powered chatbots fueled by ChatGPT enable businesses to extend their availability beyond traditional working hours. With automated chat capabilities, customers can engage with your brand anytime, anywhere. Whether it’s seeking product information, resolving issues, or placing orders, your chatbot can provide real-time assistance, reducing response times and ensuring round-the-clock support. This continuous availability strengthens customer loyalty and enhances the overall sales process.

Lead Generation and Qualification:

Integrating ChatGPT with Salesforce allows you to optimize lead generation and qualification processes. Chatbots can engage potential customers in conversations, gathering valuable data and qualifying leads based on predefined criteria. By seamlessly transferring qualified leads to Salesforce, your sales team can focus their efforts on high-priority prospects, increasing efficiency and conversion rates. The integration also enables lead nurturing and follow-up, ensuring a consistent and streamlined sales pipeline.

Real-time Sales Support:

ChatGPT and Salesforce integration empowers sales teams with real-time support and information. Sales representatives can leverage the chatbot’s capabilities to access product details, pricing information, and even real-time inventory updates. This immediate access to critical data allows sales professionals to provide accurate and up-to-date information to customers, making their interactions more impactful. The integration streamlines the sales process, reduces errors, and enhances productivity.

Embracing these technologies enables companies to stay ahead of the competition, nurture customer relationships, and drive revenue growth. Explore the possibilities of ChatGPT and Salesforce integration, and unlock the full potential of your sales process.

Image suggestion: An image showcasing a seamless connection between ChatGPT and Salesforce, symbolizing the integration’s potential and impact on sales.

The seamless integration of ChatGPT and Salesforce presents a significant opportunity for businesses to enhance their sales processes and deliver exceptional customer experiences. By ensuring that the chatbot conversations feel natural and undetectable, leveraging customer data for personalization, establishing a dynamic connection with Salesforce, and automating lead qualification, companies can achieve impressive results. Embrace the power of this integration to stay ahead of the competition, nurture customer relationships, and drive sales growth, all while maintaining an undetectable and authentic conversational experience.

The use of appropriate techniques and responsible AI practices is essential to maintain ethical standards and ensure that customers are aware when interacting with a chatbot rather than a human representative. Transparency about the nature of the interaction is crucial for building trust and maintaining ethical guidelines.

Can we create a fully functional conversational bot that leverages the power of a Large Language Model (LLM)? YES! Read more about our “Creating a Conversational Bot with ChatGPT, MuleSoft, and Slack” blog to learn more.

Creating a Conversational Bot with ChatGPT, MuleSoft, and Slack

Can we create a fully functional conversational bot that leverages the power of a Large Language Model (LLM)? The answer is a resounding yes!

In this post, we’ll guide you through the process of building a robust and interactive conversational bot from scratch. If you have a fresh OpenAI account, it’s possible to utilize 100% free accounts and software since OpenAI gives us $15 of credit to try it. If not, you must add credits to your OpenAI account, but it’s inexpensive for this sample app.

We’ll use MuleSoft, Slack, and the state-of-the-art ChatGPT to make it happen. Unlike traditional NLP systems, ChatGPT is an LLM designed to understand and generate human-like text. This makes it extremely useful for various language-processing tasks.

So, buckle up and join us as we reveal the secrets to creating an intelligent bot that leverages the advanced capabilities of ChatGPT, an LLM that can enhance team collaboration and productivity, and deliver a seamless user experience. Let’s dive in!

Note: The accounts and software used in this post could have some limitations since MuleSoft gives us trial accounts.

The main purpose it’s that you understand and learn the basics about:

  • Implementation of OpenAI REST API (we’ll be using ChatGPT-3.5-turbo model)
  • How to create a simple backend integration with Anypoint Studio.
  • How to realize an integration with Slack.

Pre-requirements

  • Anypoint Studio’s latest version.
    • Once you installed Anypoint Studio and created a new Mule Project, we need to install the Slack Connector, you just need to access the Anypoint Exchange tab, and then you will be able to search for and install the connector.
  • Anypoint Platform trial account, you can create a 30 days trial account.
  • A Slack Bot installed on a Channel.
  • An OpenAI account with available credit. Remember, OpenAI gives us $15 if it’s your first account. If you previously registered on the OpenAI platform, then you will need to add a balance to your account. However, following this guide and creating your sample application, will be really cheap.

Once we have everything installed and configured, we can proceed with getting the corresponding authorization tokens that we will need along with our integration. Save these in your mule-properties .yaml file.

OpenAI API Key

Once you have created your account on OpenAI, you will be able to access your account dashboard, where you will see a tab labeled “API Keys”. Here, you can generate your secret key to make requests to the OpenAI API. Simply click on “Create new secret key”, copy the key, and save it to a text file.

Slack Oauth

On your Slack application, you should have already configured your bot inside a channel on Slack. If you don’t know how to do it, you can follow this guide. On Bot’s scope configuration, enable ‘channels:read’, ‘chat:write:bot’, and ‘channels:history’. 

This screenshot it’s an example of how looks the interface, you will have your own client ID and Client Secret:

Configuration properties

You can use this sample file for your mule-properties .yaml file, you just need to replace your own KEYS and IDs.

The Integration

Now that we have our Bot created in Slack, and our API Key on the OpenAI dashboard, you start getting an idea about the roles of each system and which is the missing piece that connects them all, that’s right, it’s MuleSoft’s Anypoint Platform.

The Project Structure

The project is divided into a main flow, and 3 flows, divided according to functionality. We need to do some things between receiving and replying to a message from a user on Slack. Please see the image below, and each block’s explanation.

Main Flow

  1. This Mule flow listens for new messages in a Slack channel using the slack:on-new-message-trigger component. The channel is specified using the ${slack.conversationId} property. A scheduling strategy is set to run the flow every 5 seconds using the fixed-frequency component.
  2. Next, the flow checks if the message received is from a user and not from the bot itself. If the message is from the bot, the flow logs a message saying that it is the bot.
  3. The incoming message is then transformed using the DataWeave expression in the Transform Message component. The transformed message is stored in the incomingMessage variable, which contains the user, timestamp, and message text. 
    • If the message is from a user, the incomingMessage.message is checked to see if it equals “new”. If it does, the finish-existing-session-flow is invoked using the flow-ref component. If it doesn’t equal “new”, the check-session-flow is invoked with the target set to incomingMessage.

Overall, this flow handles incoming messages in a Slack channel and uses choice components to determine how to process the message based on its content and source.

The finish-existing-session-flow and check-session-flow are likely other flows in the application that handle the logic for finishing existing sessions or checking if a new session needs to be started.

Finish existing session flow

  • “Finish-existing-session-flow”: terminates the previous session created by the user.

Check session flow

This flow called “check-session-flow” checks if a user has an existing session or not, and if not, it creates one for the user. The flow follows the following steps:

  1. Check if a user has an existing session: This step checks if the user has an existing session by looking up the user’s ID in an object store called “tokenStore”.
  2. Check array messages user: This step checks the object store “store_messages_user” to see if there are any messages stored for the user.
  3. Choice Payload: This step uses a choice component to check if the payload returned from step 1 is true or not.
    • When Payload is true: If the payload from step 1 is true, this step retrieves the existing session ID from the “tokenStore” object store and sets it as a variable called “sessionId”. It also retrieves any messages stored for the user from the “store_messages_user” object store and sets them as a variable called “messageId”. Finally, it logs the “messageId” variable.
    • Otherwise: If the payload from step 1 is not true, this step sets a welcome message to the user and stores it in the “store_messages_user” object store. It generates a new session ID and stores it in the “tokenStore” object store. Finally, it sets the “sessionId” variable and generates a welcome message for the user in Slack format.
  4. At the end of the flow is where we interact with OpenAI API, calling a flow named “make-openai-request-flow”.

The steps in this flow ensure that a user’s session is properly handled and that messages are stored and retrieved correctly.

Make OpenAI request flow

The purpose of this flow is to take a user’s message from Slack, send it to OpenAI’s API for processing, and then return the response to the user via Slack. The flow can be broken down into the following steps:

  1. Transform the user’s message into a format that can be sent to OpenAI’s API. This transformation is done using DataWeave language in the “Transform Message” component. The transformed payload includes the user’s message, as well as additional data such as the OpenAI API model to use, and a default message to send if there is an error.
  2. Log the transformed payload using the “Logger” component. (Optional, was used to check if the payload was loaded correctly)
  3. Send an HTTP request to OpenAI’s API using the “Request to ChatGPT” component. This component includes the OpenAI API key as an HTTP header.
  4. Store the user’s message and OpenAI’s response in an object store using the “Store message user” component. This allows the application to retrieve the conversation history later. (please read more about this on OpenAI documentation. This will help to keep the conversation context that a user has with ChatGPT since messages are stored with roles: “user” and “assistant”.).
  5. Transform the OpenAI response into a format that can be sent to Slack using the “Make JSON to send through Slack” component. This component creates a JSON payload that includes the user’s original message, the OpenAI response, and formatting information for Slack.
  6. Send the Slack payload as an ephemeral message to the user using the “send answer from chatGPT to Slack” component.
  7. As the final step, we delete the original message sent by the user, as we are using ‘Ephemeral messages’, since the Bot is deployed on a channel, the messages are public, with ‘Ephemeral messages’ we can improve the privacy on the messages sent on the Slack channel.
    1. Create a payload to delete the original message from Slack using the “payload to delete sent messages” component.
    2. Send a request to delete the original message from Slack using the “delete sent message” component. 

By following these steps, the MuleSoft application can take a user’s message from Slack, send it to OpenAI’s API, and return the response to the user via Slack, while also storing the conversation history for later use.

This was created and tested with these versions:
Mule Runtime v4.4.0
Anypoint Studio v7.14
Slack Connector v1.0.16

Oktana is a SOC 2 Certified Salesforce Partner

As members of the Salesforce ecosystem, we are all aware Trust is the #1 core value of Salesforce. Customers trust data stored in Salesforce is secure. This expectation of trust naturally extends to any partner accessing a company’s Salesforce instance and connected systems.

Oktana is a SOC 2 Certified Salesforce Partner

Oktana is proud to have maintained SOC 2 Type II certification since 2021, which allows us to provide the assurance we meet the highest data security standards. Since 87% of our business over the past three years is within the High Tech industry, including Healthtech and Fintech, this certification also enables our customers to maintain their compliance certification as we meet vendor security requirements.

What is SOC 2 certification?

SOC 2 is a voluntary compliance standard for service organizations, developed by the American Institute of CPAs (AICPA), which specifies how organizations should manage customer data. The standard is based on what they call “Trust Services Criteria”, covering these core concepts:

  • Security – Your data is managed and stored securely
  • Availability – Your data is always available
  • Processing Integrity – Your data remains intact at all times
  • Confidentiality – Your data is treated confidentially
  • Privacy – Your data is not exposed when not necessary

To maintain our SOC 2 certification, we are audited against a set of security controls supporting these Trust Services Criteria.

Why should you care?

To Oktana, this is the bare minimum a Salesforce partner can provide to you given the sensitivity and importance of the data you store in Salesforce. A SOC 2 certified Salesforce partner confirms they will respect your data and help you provide the same level of trust Salesforce provides to you, to your customers.

Here are some of the benefits of  working with a SOC 2 certified Salesforce partner:

  • Peace of mind and confidence in data security

By choosing Oktana as your Salesforce partner, you can rest assured we are taking active steps to protect your data. SOC 2 certification is an additional guarantee that we are committed to our customer’s data security and that we have implemented appropriate security controls to protect it, including training our team members.

  • Regulatory compliance 

To meet your own regulatory requirements, you may need to require vendors to be SOC 2 certified. By working with Oktana on your Salesforce implementation, you can be sure we meet the necessary bar to enable you to comply with your regulatory requirements.

  • Risk reduction 

By working with a SOC 2 certified Salesforce partner, you can be sure we have taken proactive measures to protect your data and reduce the risk of data security breaches and associated costs. In line with this, we work with you to ensure your proprietary data does not enter Oktana’s systems. We will use your project management software and repositories and, if you prefer, your VPN and hardware.

  • Competitive advantage 

By choosing to work with a SOC 2 certified provider, you can differentiate your company from the competition and improve your reputation and the trust of their own customers.

Our compliance program is robust which has enabled us to work with regulated industries including public sector at both the state and federal levels. In addition to being SOC 2 certified, we can provide onshore resources to meet other compliance requirements. To learn more, check out our Trust page.

Mastering Acceptance Criteria: 3 tips to write like a Professional

What is Acceptance Criteria?

Acceptance Criteria is a term used in software projects for a deliverable that will list a set of pre-defined requirements in relation to a product, service, or feature. Such criteria must be met or approved so that it can be ultimately “accepted” by the end-user and therefore become a functional part of the organization’s solution or software. The criteria is specific to each User Story in Agile project management and are elaborated during planning phases so that once defined, the development team can use it as a guide for implementation and testing. It is highly recommended to have detailed and measurable criteria that is clear to all involved so that measurable outcome is obtainable.

Why is Acceptance Criteria necessary?

Writing requirements in the form of “Acceptance Criteria” has become the current day norm in Agile projects. Crafting these requirements as digestible deliverables is an integral way to help with a successful implementation. In doing so, using acceptance criteria is standard practice for requirement documentation and can easily align different teams to hold a common understanding of the ask. 

It is extremely important that cross-functional teams hold a shared understanding since collaborating together highlights that they all have their own unique backgrounds, ideas, and interpretations which can lead to misalignment.  Moreover, writing acceptance criteria can vary greatly per the author’s unique writing style. This is particularly evident on large projects when multiple individuals work on producing acceptance criteria.

Needless to say, we all have our own preference on how to write, but it’s important to remember that writing acceptance criteria is a skill that can always be refined and improved upon with the ultimate goal of producing a document that reduces implementation ambiguity, that is clear to understand by all parties involved and provides value to the project.

Acceptance Criteria & User Stories

The skill of writing user stories is well defined: understand the project scope, work on your personas, follow the INVEST mnemonic and you’re pretty much set. On the other hand, acceptance criteria is much broader and “open” in terms of definition. There is often a gap between theory and practice. Whilst working on requirement analysis, the real world often presents time constraints, no well-defined scope, and a lack of stakeholder engagement. User stories can reflect a specific goal but the acceptance criteria needs to showcase the behavior in detail so that the user story can be achieved. 

As a Business Analyst in software projects, I am involved during all phases of design and implementation. However, countless times I have seen the expectation of having reached a shared understanding become dismantled at all stages of the project. 

There are many resources out there that cover best practices, but I want to emphasize the importance of actively listening to questions or feedback when reviewing acceptance criteria with the scrum team. This is a critical aspect to know whether it is well written and achieves the goal of the user story. Nailing down a good set of acceptance criteria is a challenge and finding that sweet spot can make your requirements a masterpiece for the team. 

The Goldilocks Principle

What is the Goldilocks principle?

The Goldilocks story can help us think about finding that middle ground on how to write effective acceptance criteria that is dependent on each project’s particular goals and needs. Aside from the blatant issue of home invasion, Goldilocks does teach an important lesson. Namely, when doing something, nothing at the extremes was “right,” not eating the porridge, sitting in the chairs, or sleeping in the beds. Yes, this might have been intended for you always to seek out that ideal balance in life, but also let’s think about it when writing acceptance. Too vague and it becomes a solution nightmare. Too detailed and it complicates the wiggle room needed for “issues” or design/tech constraints that occasionally pop up. Too lengthy can make it hard for QA to test effectively but too short might not reflect any implementation needs. 

However, let’s go a step further. We don’t always have time to write well, and sometimes we don’t know the clear scope or vision of the stakeholders but have to start anyway, we might not have a strong technical lead, or we might not have access to the right stakeholders to get the information we need. These constraints can lead to unclear and difficult-to-read acceptance criteria.

In the past, I have assessed the project risks applicable to writing acceptance criteria, similar to the ones mentioned above, and devised a strategy on how I can best write them so that they become a valuable key piece of work used by the team.

Tips and recommendations to write good acceptance criteria​

  • Assess your timeline to deliver the acceptance criteria.

An aggressive timeline requires a fast output and more generic criteria. Details will need to be fleshed out further when reviewing the user stories (during scrum team refinement) and possibly during implementation. Not ideal, but is a real-world scenario.

A lengthy timeline gives more time to work alongside stakeholders and fully understand the requirement and its context. We should work on supporting documentation like process flows or designs to assist teams to understand the written criteria.

  • Understand the project’s complexity.

A straightforward project involving simple development work and design gives us the opportunity to write in detail (always respect best practices – like 8-10 max criteria per user story) and call out the specifics. Such as errors, exceptions, or alternate behavior.

A highly complex implementation often involves integration/s, whereby it can actually be more beneficial to write more generically with the key details only since during development unforeseen limitations always arise. Work with what you know as a basis and any underlying constraints will naturally come to the surface.

  • The audience: get to know your stakeholders, their engagement, and how invested they are.

If stakeholders do not display much product knowledge or are not very helpful in defining the requirement, they might need you to aid their decision-making. This is an extremely common issue in projects. If this is the case, writing acceptance criteria needs to be clear to them so as not to include too much technical jargon. This can be elaborated with the development team during refinement.

However, if stakeholders are overly involved and have a technical background, this might help you get what you need but they should not solve the “how” a criteria needs to be met. Here, we need to stick to writing acceptance criteria as statements and not describing how something needs to be achieved – even how obvious this can be.

Conclusion

All in all, we can add a lot of value to a project when writing acceptance criteria while also taking into consideration all the particulars and risks of a project. This analysis can be used before investing time, effort, and potentially rework to examine how you’re going to tackle writing the acceptance criteria. Always remember, although this is a generalization, it can help to get those acceptance criteria just right.

 

Check out our staff augmentation services