Example use cases
Let's assume that you are planning to offer a digital application for your end-users to help them with data breach reports or you are using BRYTER to help the HR team with job applications.
Example 1 - Data Breach Assistant as a Service
On a high level, your application will consist of a the following elements: 1) assessment, 2) generic report of data breach if required, or 3) specific security breach reports for the end-user's organization, e.g., for telecoms and internet service providers.
Previously, most users would have combined all of the above described elements in one single module - even though element 3, for example, would occur less frequent than element 2 and would only be triggered if the end-user had selected 'telecoms and internet service providers' during the self-assessment in element 1.
Now, Services allow authors to organize these elements as separate modules and manage them easier. The Service Data Breach Assistant would thus contain 3 (or more) separate and much smaller modules. Each module has one distinct purpose:
Module A - Data Breach Assessment helps with identifying whether the breach in question indeed needs to be reported and might contain a severity assessment. The module also assesses whether the data breach report should follow the generic or specific report requirements.
Module B - Generic Report will guide the user through all questions required to fill in a generic report. Information gathered in Module A can either be transferred with URL Parameters or soon databases.
Module C - Specific Report is only required for certain organizations. If the end-user selected this type of organization in Module A, using a combination of Redirect Results and URL Parameters or soon databases will guide the end-user to this module. Inputting additional information and transferring already entered information will populate the relevant template for the organization type.
Example 1 - Step-by-step process
1. Create a new Service called 'Data Breach Assistant'.
2. Share the Service with everyone involved - maybe one person in your team is responsible for Module A whereas another team member is focused on document automation and will build Module B and Module C.
3. Build your Modules and publish all Modules to the same environment (Test or Live).
4. Ensure that you connect modules where possible using Redirect Result.
5. Pass on information between Modules with URL Parameters or by reading information from the Service database (soon).
Example 2 - HR - Job Application Assistant
Your HR team wants to establish a unified process to handle job applications. They are interested in both providing external end-users, the applicants, a nice interface to enter their data and to answer assessment questions and want to also easily review and follow up each incoming application. In this use case example, you have 1) an external facing module for the applicants and 2) an internal review and assessment module for the HR manager along with 3) an internal scheduling app for the hiring manager.
Module A - Applicant Intake Questionnaire helps to gather applicant data in a structured manner and could be potentially used to pre-assess an applicant. The module also notifies the correct reviewer depending on the department or seniority level.
Module B - Review Applicants Screener will guide the reviewer in a structured manner through all the required screening steps and help assess against defined standards. Information gathered in Module A could be either transferred with URL Parameters and a unique URL sent via email or soon with databases.
Module C - Interview Scheduling App assists with offering the applicant and the interviewers only pre-agreed time slots and can be used to help with interview preparation.