- If designers publish production forms/workflows from their individual designer accounts and edit a production form/workflow, they will be editing a live form. This does not give any source code / QA control.
- If there are multiple designer publishing production forms/workflows from their own accounts, then your production forms/workflows will be scattered around between different user accounts and it will be more challenging to maintain them.
- The username of the user account where the form/workflow is published is used in the form/workflow URL and you might not want the username to be known to all other form users.
- Designer users have permission to view submissions. Publishing in a generic production account prevents the designer from viewing production submissions.
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/workflows 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.
- Assign the frevvo.Publisher role to one or more other users.
- When a designer is ready to deploy a form/workflow/project for production or update one already in production, the designer will download the form/workflow/project zipfile and check it into a source code repository (outside of a frevvo server).
- A user with the frevvo.Publisher role will check-out the new form/workflow/project from the source code repository (outside of a frevvo server) and upload/replace the form/workflow/project into the generic production user account.
To deploy a form/workflow for the first time, you must then log in as the Production User, select the form/workflow, and click Deploy.
To update a form/workflow that is already in production, check "replace" on the upload screen. The deployment state of the form/workflow being replaced will be maintained for the updated version.
Updating a Form or Workflow in Production
- The only way to guarantee the same behavior for both tenants is to configure both with the same security manager.
- Each tenant should point to its own instance of your security manager.
- For example if you are using LDAP, a development LDAP domain with a set of LDAP groups that are EXACTLY the same as your production LDAP domain is suggested. This way workflows can be moved from your development tenant to your production tenant and workflow navigation w/roles is guaranteed to work correctly.
- The generic production user account (ex: "production") must be created in your IDP (LDAP, Azure, SAML).