...
...
...
...
...
...
| Section | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- 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.
Tip 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
...
| Info |
|---|
When a production workflow 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 workflow and change business rule or add/remove fields, all the pending tasks pick up the latest version of the workflow. Pending tasks for a form/workflow that integrates with a Google sheet reflects any changes made to the Google sheet while the tasks are in-flight. When uploading a form/workflow with the same ID as an existing form/workflow, without checking Replace, a copy will be created and the designer will see an error message: "The form/workflow that was uploaded matches the id of one that already existed so a copy was made. If you intended to replace the existing form/workflow, delete the form/workflow you just uploaded and upload it again but check off the ‘Replace’ option." When uploading a form/workflow with Replace checked that is currently being edited by another user, the designer will see this error message: "This form/workflow is currently being edited by <user@tenant>. Please try again later." |
Form/Workflow designer edit ACL
The Access Control feature in allows the designer to assign other users permission to make changes to forms and workflows.
| Warning |
|---|
The ability to edit a form/workflow should not be given to other users if the form/workflow 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. |
Multi-Tenant Scenario
Development Tenant
...
- 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).
...