Want to find out more about Services? Watch the recording of our webinars on Services in February and March.
What are Services?
Services 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 Services, you can group modules that make up a specific use case and share these in one go with other Service collaborators. For example, a Service 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.
Services 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 Service unit since they work closely together and do not need to be manually removed or added to each module.
Additional information on Services can also be found in our dedicated FAQ Services article.
Why do you need Services?
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"). Services are our answer to that.
Each use case that you want to automate with BRYTER is a Service. Services 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 (Service) collaborators can see and change all constituent parts; they need only be invited to the project, rather than to each part individually.
Services also help with making your existing modules easier to manage, review, and maintain. Since a Service 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 Services?
By introducing Services, the architecture of your BRYTER Dashboard will change and you will now see a grid of your Services (not modules) after logging into your BRYTER platform.
After clicking on a Service, you will see a list of modules that are part of the Service:
First steps after Services have been introduced
Once Services are available, you will see that each module is wrapped in its own project. Every single module you own or can access as collaborator will now be a Service of the same name. Please note that all previous module collaborators will now be collaborators in the Service of the same name.
To group modules together, move them to the same project. Keep in mind that moving a module to a new or different Service will also influence the Service structure for all collaborators.
All Modules will now be visible in the target Service. Ensure that all collaborators of the original Modules are also Service collaborators.
You can now delete the empty Service:
For a step-by-step guide on how to set up your very first Service, visit how to build your first Service here.
How do I add collaborators to a Service?
With Services, authoring access for collaborators is managed on the Service level, rather than on a module level. This means that anybody who collaborates on the Service can view and edit all its modules and databases. This makes sense because all modules in a Service are interconnected and should thus be managed and edited by the entire Service collaborator team.
Like this, teams of authors can also 'declutter' their dashboards by grouping their modules together into Services. New authors or colleagues joining can be easily added to all the modules contained in the Service. Likewise, if an author or project member is leaving and should be removed from all modules in the Service, they can be removed from the Service to revoke access from all its modules.
How do I copy a Service?
In the settings of a service, you can duplicate a Service. This will create a copy of the service including all its modules and case databases.
Once the duplication was successful, you can click on Open service copy to switch to the newly created service. Please note that collaborators are not copied but have to be added to the newly created Service.
What can I build with Services?
Currently, Services are the ideal way to group together modules that work together and consititute one use case. Let's consider a Data Breach Assistant as an example use case for Services: The Assistant is used to (1) report and identify data breaches, (2) assess the risks and recommend mitigation strategies, and to (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 a Service 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 to update the orginal 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 Services
- 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 Services
We highly advise against using Services 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 Service.
💡 Best practices
- Define one collaborator who is in charge of arranging your modules into Services
- Give your Service a clear name to ensure that the purpose of the modules contained in this Service is reflected
- Consider renaming the modules in your service to reflect their order or their purpose (e.g., document generation, information intake, assessment)