Note on legacy behavior: "Service" renamed to "Application"
What previously was called Service within the BRYTER platform is now renamed to Application making it more self-explanatory and convenient for our customers.
Further, the Service Frontend is now referred to as Publish Application.
What are Applications?
Applications are your new "unit" for use cases that consist of more than just one module and will enable you to arrange and manage your modules better. With Applications, you can group modules that make up a specific use case and share these in one go with other Application collaborators.
For example, an Application called "Vacation Request" would contain several modules with different purposes and different interfaces for different people: Module A would consist of an interface for requesters, a person who wants to log their vacation, whereas Module B would be geared towards the approver, a line manager or the person the requester reports to.
Applications thus allow you to organize your modules based on the process you are looking to automate and to share these modules in one go with the right collaborators. Collaborators are now added to the entire Application unit since they work closely together and do not need to be manually removed or added to each module.
Additional information on Applications can also be found in our dedicated FAQ Applications article.
Why do you need Applications?
Since we started with BRYTER, we have learned that most use cases - processes or service flows that authors want to automate with BRYTER - consist of more than just one module. Instead, different types of users (e.g. "employees" and "managers") use different modules (e.g. "request vacation" and "approve/reject" modules, respectively) to work on the same case (e.g. an "absence request"). Applications are our answer to that.
Each use case that you want to automate with BRYTER is an Application. Applications group and circumscribe the things that need to work together for a use case, e.g. multiple modules that redirect to each other or that work on the same data. All authors who have been made (Application) collaborators can see and change all constituent parts; they need only be invited to the project, rather than to each part individually.
Applications also help with making your existing modules easier to manage, review, and maintain. Since an Application helps with bundling modules, you could consider partitioning existing modules and have modules dedicated to, for example, gathering information, creating documents, or approving requests.
How do you use Applications?
By introducing Applications, the architecture of your BRYTER Dashboard will change and you will now see a grid of your Applications (not modules) after logging into your BRYTER platform.
After clicking on a New Application and Modules, you will see a list of modules that are part of the Application:
First steps after Applications have been introduced
Once Applications are available, you will see that each module is wrapped in its own project. Every single module you own or can access as a collaborator will now be an Application of the same name. Please note that all previous module collaborators will now be collaborators in the Application of the same name.
To group modules together, move them to the same project by selecting the Module and selecting Move to. Keep in mind that moving a module to a new or different Application will also influence the Application structure for all collaborators.
All Modules will now be visible in the target Application. Ensure that all collaborators of the original Modules are also Application collaborators.
You can now delete the empty Application in the Settings of your Application.
For a step-by-step guide on how to set up your very first Application, visit how to build your first Application here.
How do I add collaborators to an Application?
With Applications, authoring access for collaborators is managed on the Application level, rather than on a module level. This means that anybody who collaborates on the Application can view and edit all its modules and databases. This makes sense because all modules in an Application are interconnected and should thus be managed and edited by the entire Application collaborator team.
Like this, teams of authors can also 'declutter' their dashboards by grouping their modules together into Applications. New authors or colleagues joining can be easily added to all the modules contained in the Application. Likewise, if an author or project member is leaving and should be removed from all modules in the Application, they can be removed from the Application to revoke access from all its modules.
How do I copy an Application?
In the Settings, you can duplicate an Application. This will create a copy of the Application including all its modules and case databases.
Once the duplication was successful, you can click on Open Application copy to switch to the newly created Application. Please note that collaborators are not copied but have to be added to the newly created Application.
What can I build with Applications?
Currently, Applications are the ideal way to group together modules that work together and constitute one use case. Let's consider a Data Breach Assistant as an example use case for Applications: The Assistant is used to (1) report and identify data breaches, (2) assess the risks and recommend mitigation strategies, and (3) generate documents for incident reports or notifications
In a future iteration, you will also be able to store the data relevant for several Modules within an Application in a native database. Like this, you can use Module A to gather information and store the information in a database while Module B reads the gathered information from the database. This could enable an approver, who is using Module B, to review the information gathered in Module A and to add further information to the database or update the original database entries. Further, Module C might combine information gathered in both Module A and Module B to generate documents by reading from the underlying database.
Use case examples and best practices
👍 Good use of Applications
- Vacation request/approval containing separate modules for vacation requests and vacation approvals
- GDPR data breach containing several modules for data breach assessment, report generation, and mitigation checklist creation
- NDA generator containing several modules for unilateral, bilateral, multilateral, or NDAs
- Duplicated modules or different versions of modules, e.g., Gift Policy v3.1 and Gift Policy v3.2
👎 Bad use of Applications
We highly advise against using Applications to group all your modules in a folder structure, e.g. simply collecting all your modules or all modules that fall into a certain legal area into one Application.
💡 Best practices
- Define one collaborator who is in charge of arranging your modules into Applications
- Give your Application a clear name to ensure that the purpose of the modules contained in this Application is reflected
- Consider renaming the modules in your Application to reflect their order or their purpose (e.g., document generation, information intake, assessment)