There are many paths to Rome.... frevvo suggests the following best practices for managing your tenants, applications, forms and flows.
|
|
Multiple Live Forms server installations are the most flexible and best practice for maintaining a production environment. In this scenario, you may have a development server, a test/staging server and a production server. Or you may have only a development server also used for testing and a production server for deployed forms/flows.
Create roles and users in your development environment. If you are using the default security manager, simply create the users and roles in the tenant, otherwise refer to customers using the LDAP/SAML/Azure Security Manager.
The role names in your development environment should be the same as the role names in your production environment. If they are different, modifications to your workflows will have to be made to users and workflows to reflect the production roles when they are moved to the production. |
Create a generic production user account (ex: “production@<your tenant>”) in your production environment and give this user the frevvo.Designer role. All your production forms/flows will be in this user account.
If you are using a non-default security manager, this step and the next step would be done via your IDP software. |
When a designer is ready to deploy a form/flow to production or update one already in production, a frevvo.Publisher will check-out the new application from source code (a repository outside of a frevvo server) and upload/replace the application into the generic production user account in your production environment.
The tenants in your development and production environments may have the same name although this is not required. |
We recommend that all in-house customers with a single server have two tenants: a development/test tenant and a production tenant. A separate development/test tenants is recommended for the following reasons:
Follow the setup steps above for In-house Test/Staging Server Installations. The only difference is that in your case your "test environment" is simply a dev/test tenant on the same server as your "production environment" and not a separate server.
Cloud customers have a single tenant. In this scenario, best practices are to create a set of test roles and test users. Your form/flow designers will use test roles/users during the dev/test phase.
Cloud customers may optionally purchase a 2nd tenant for development and testing.
We recommend that the forms/flows be created & tested by one/multiple designers in their own accounts. After the forms are designed/tested, they can be downloaded from the individual designer user accounts and uploaded to a generic production user account (ex: “production@<your tenant>" where the forms can be published and used by your end users.
We recommend using a generic production user account to publish apps/forms/flows into production for the following reasons:
Follow these best practices:
Create a generic production user (ex: “production@<your tenant>”) and give this user the frevvo.Designer role. All your production forms/flows will be in this user account.
If you are using a non-default security manager, this step and the next step would be done via your IDP software. |
If you need to update a form/flow that has been deployed to production, there are specific steps to follow to avoid issues with submissions. Submissions are tied to a specific form/flow. It is very important that you make your changes to the form/flow that has the same typeId as the production version. This ensures that the production version of your form/flow will be replaced by the updated version when you upload it to your production account and check the Replace checkbox on the Upload screen.
Let's say you have a form/flow in production that requires some changes. Follow these steps:
The typeId of a form/flow can be seen in the URL when you edit it in the form/flow designer.
When a production flow that has pending tasks associated with it is edited and replaced with an updated version, pending tasks will contain the changes the next time they are "performed" from the task list. For example, let's say you
When you edit a flow and change business rule or add/remove fields, all the pending tasks pick up the latest version of the flow. Pending tasks for a form/flow that integrates with a Google sheet reflects any changes made to the Google sheet while the tasks are in-flight. |
The Access Control feature in allows the designer to assign other users permission to make changes to forms and flows.
The ability to edit a Form/Flow should not be given to other users if the form/flow is in production. Giving this permission would enable those users to edit your production forms directly thereby subverting the best practices described in this guide. |
It is best to have the roles in your test tenant match the roles in your production tenant. This enables testing of forms/flow in development for ACL and navigation without having to edit your form/flow before deploying the updated form/flow to production.
Create test users in your development tenant. If you are using the default security manager, simply create the test users in the tenant. Refer to Customers using the LDAP/SAML/Azure Security Manager if you are not using the default security manager.
The role names in your development tenant should be the same as the role names in your production tenant. If they are different, modifications to your workflows will have to be made to users and workflows to reflect the production roles. |
When further updates/modifications are required, the forms/flows should again be edited in the designer user accounts and then upload/replaced in the generic production user account.
If you are testing in a multiple tenant scenario, we recommend that both your dev/test and production tenants are configured with the same security manger. This is recommended for the following reasons:
