We maken BizzStream steeds beter om uw bedrijfsprocessen te kunnen automatiseren. Omdat we u een stem willen geven in de ontwikkeling van BizzStream kunt u hier Feature request plaatsten. Iedere gebruiker kan stemmen op een feature, de feature met de meeste stemmen zal op de roadmap van BizzStream komen.
As an administrator, I want to set the number of initially displayed documents and display a placeholder so that they are aware that there may be more results.
(WHY) When users expand reference fields, they initially see 5 items. When they enter a search string, they will see at most 5 items that match the search string. This confuses some users.
(WHAT) Set the number of suggestions and display a placeholder
In the past, reference fields showed at most about 20 references. As a result, scroll bar was typically visible when a reference field was expanded. As a result, users were inclined to use the search box to find an item.
Due to performance considerations, we limited the list to 5 items. Now users are suddenly much less inclined to use the search field and complain that not all items are visible.
This story consists of three parts:
- Setting the number of suggestions
- Displaying a placeholder
- Show indicator if there are more suggetions
Set Number of Suggestions
In some cases, limiting the search results to 5 items is too restrictive. We want to give administrators the option to increase this. To do so, the administrator
- Opens the document definition
- Opens the settings of a reference fields
- Enters a value in the Number of Suggestions box (see mockup 1). This field is a numeric input an the maximum value is 20.
- Clicks on Save to update the field
- Clicks on Save to store the document definition
When the user opens a reference field, he should see an placeholder that tells him to enter a search text. On desktop, this is a placeholder visible in the text field (see mockup 2). On mobile, the existing placeholder (Search...) should be replaced by Enter Search Text (see mockup 3).
Indicating More Suggestions
If there are more documents that meet the search terms than the maximum number of suggestions set by the administrator, BizzStream should show a warning indiction, both on desktop (see mockup 4) and on mobile (see mockup 5).
Screenshot 1: The reference field in the past, on desktop
Screenshot 2: The current reference fields, with a limited number of items
Mockup 1: The Number of Suggestions field
Mockup 2: A reference field on desktop with a placeholder
Mockup 3: A placeholder in the mobile search field
Mockup 4: The more suggestions indicator on desktop
Mockup 5: The more suggestions indicator on mobile
As an administrator, I want to increase size of Header Field in a REST call rule so that it is easier to configure the rule.
(WHY) The box is fairly small, which makes it hard to configure REST call rules.
(WHO) An administrator
(WHAT) Increase the header field
The header field is fairly small (see screenshot 1).
The header field is bigger (see mockup 1).
Screenshot 1: The existing header field
Mockup 1: The new, larger, header field
At this moment you can only use fixed dates in the filter of a menu item, e.g. show every record after 01-09-2017. This means you will have to change the filter every time when you only want to show the reconds of this month.
If you could choose variables like "this year", "last year", "this month", "last month", "today", "yesterday", "this week", "last week" then this gives a lot more flexibility without having to change the filters.
As an administrator, I disable toolbar buttons when a menu item is in edit mode so that have to press Update or Cancel before I can continue.
(WHY) Administrators sometimes forget to save changes because they click directly on Save without hitting the Update button of a menu item first. As a result, they accidentally lose changes.
(WHAT) Disable the toolbar buttons when a menu item is in edit mode
To edit a menu item, an administrator:
- Opens a menu
- Clicks on the Menu Item
- Clicks on Edit
- Makes the changes
- Clicks on Update
- Clicks on save to persist the menu
When the user presses Update or Cancel, so that the menu editor leaves the edit mode and the Back, Save, and Delete buttons get enabled again.
Screenshot 1: A menu item in edit mode.
As an administrator, I would like to display user action buttons conditionally so that I can reduce the number of statuses.
(WHY) Depending on the status of a document, user action buttons are displayed. However, sometimes there is need for more fine-grained control.
(WHAT) Conditionally display user action buttons
Currently user action buttons are displayed based on the status of a document. To hide a button, the status of a document needs to change.
This is not always desirable:
- Sometimes we want to show/hide a button based on a condition (say a checkbox that is marked). This condition does not necessarily represent a new "stage" in the business process.
- By adding a large number of statuses to the document, the document definition itself gets big.
This story consists of two parts:
- Setting the condition
- Show/hide the button conditionally
Set the condition
To set the condition, the administrator
- Opens the document definition
- Opens the Workflow section
- Double clicks on a user action so that the user action dialog opens
- Enters the condition in the Display Only If box
- Clicks on Ok to close the User Action dialog
- Clicks on Save to persist the document definition
Show/hide the button conditionally
A user action button is displayed if:
- The document has the status to which the user action button is linked (already in place)
- The user is an administrator or belongs to an access group that has access to the user action (already in place)
- If there is a condition, the condition is met
This last step has to be implemented for both desktop and mobile.
Mockup 1: the User Action dialog with the Display Only If field
As an administrator, I would like to see the document IDs in the logs so that I can investigate how and by whom a document was updated.
(WHY) Sometimes users dispute whether they changed a document. The logs contain a lot of information about (user) actions that updated a document, but it is not easy to find the relevant information because the document ID is not stored in a separate column in the logs view.
(WHAT) Add a document ID column to the logs view
The document ID of affected documents is not shown in the logs overview.
1. Show the Document ID column
When the user goes to Setup > Logs, the logs column is displayed (see mockup 1).
2. Add the field to the filter
Make it possible for the administrator to filter on documentId.
3. Add document
When writing logs, the document ID should be added. Logs are added when:
- A user action is executed
- A scheduled action is executed
- A script is executed
- An e-mail is send
- REST calls are made
At all these places, make sure that the document ID is added to the logs.
Mockup 1: The Document ID column in the logs.
For example in lines, formula fields for calculating is needed when multiplying the unit price and number of an item. Then it would be possible to calculate the subtotal of a line.
First, only the calculating with the available fields in a document would be great.
As an administrator, I want to be able to show a link in layout so I can link to another document in BizzStream or to external websites.
Why: This gives the possibility to switch to a related document without having to search again (This adds another layer to the menu structure in BizzStream). This also gives the possibility to link to video's for workinstructions on Youtube or to workinstructions on the suppliers website a.s.o..
What: add a field type "URL" + property "Open in new tab".
Current situation: you cannot add a document related URL in a specific document (only in a user action but that URL then relates to all documents in the document system).
Acceptance criteria: you can add fields with field type URL to a document. You can choose wether the URL will open in a new tab or stays within the same. The entered URL is validated. If you click or tab on the URL, the webpage is opened.
As an administrator, I want to restrict the size of a signature field so that I don't have to deal with signatures that have various sizes.
(WHY) The size of the signature field depends on the user's device. As a result, signatures may have different sizes, which makes it difficult to deal with.
(WHAT) Restrict size of signature field
The size of the signature field depends on the user's device. As a result, signatures may have different sizes, which makes it difficult to deal with.
When a signature field is very wide, users tend to put the signature in one part of the field (see screenshot 1).
When the signature field is rendered on another device, it is resized in such a way that its aspect ratio got lost. This is undesirable.
We try to store images in the same aspect ratio, so that it is relatively easy to resize those signatures.
We use an aspect ratio of 1/6. For each pixel that the signature field is width, it is 1/6px height. So when a reference field is 600px width, it is 360px height)
Screenshot 1: A signature in a very wide signature field
Screenshot 2: The signature rendered on a mobile device
As an administrator, I want that the guard rule terminates a user action if a user does not confirm so that accidental mistakes are avoided.
(WHY) Some user/bulk actions may have consequences that are hard to revert. In this case, is is desirable to be able to ask the user to confirm that he wants to start an action.
(WHAT) Add confirmation functionality to guard rules in user actions
When a Delete Document rule is part of a user action, a confirmation is shown. Apart form that, no confirmations are shown to the user when an action starts.
This story consists to two parts:
- Adding the rule
- Asking a confirmation when the rule starts
Add the Guard rule
To add a rule, the administrator completes these steps:
- Open a document definition
- Go to the workflow section
- Opens an user action
- Click on insert and then on Guard
- Enters the confirmation text in the Confirmation box (see mockup 1).
- Clicks on Update to remember the changes
- Close the action dialog
- Click on Save to persist the document definition.
BizzStream determines as follows up to what point rules are executed:
1. BizzStream will show a confirmation dialog (see mockup 2) for each of the Guard rules with a confirmation question.
2. If a confirmation dialog is cancelled, no further confirmation dialogs are presented to the user. BizzStream will ask the server to execute the rules up to the Guard rule that was not confirmed.
3. On the server the rules up to the Guard rule that was not confirmed are executed. If one of these rules throws an error or a Guard rule is triggered via the Execute Only If functionality, the user action is interrupted at that point.
Note: A guard rule with a confirmation dialog can thus interrupt the user action if the Execute Only If condition resolves to true, even though the user clicked Ok in the confirmation dialog.
Mockup 1: The confirmation properties in the Guard rule
Mockup 3: The confirmation dialog
Customer support service by UserEcho