We are enriching BizzStream with more and more functionality. Because we want you to participate in building the best possible platform, we give you the opportunity to add feature requests and vote for the best ones. We will prioritize the features and plan them on our roadmap.
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
Currently, we have to check alot of boxes if we want to disable a field across all statussus.
CURRENT SITUATION - all boxes have to be checked. Which takes a lot of time if you have to do for example 10 fields
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.
Our customer GP Groot has asked us to provide more insight into the usage of the system.
At the moment it only possible to see the usage per month. A view suggestions to make thing better from GP Groot, VanWerven (where I'm on location at the moment) and myself:
- stack the monthly / daily bar with documents per document system. So that the monthly-bar contains the docdef (or 10 most used) and show that part of the bar in a different color. Like this:
AND / OR (less work?))
- make it possible to "filter" on document system, in order to see how much each "functional process" is used
- when clicking on a month bar, "zoom" in to an overview per day
- make it possible to filter on values (like companyId) , in order to see how much documents are created per business unit. This will allow the customer to charge to usage of the bizzstream to the correct business unit. This one is tricky; but I'm thinking that we might want to filter on "master data" doc-def Id's
Perhaps an export option to send detailled information is already sufficient to achieve this thirth point.
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.
At the moment Its not possible to send out a rest-call that contains the content of
An attachment field.
If the platform Could be extended to send out the content of attachment, we Could send attachment off for storage in external systems like Corsa and sharepoint. Or Metacom DMS.
We would need support in scripted and modelled REST-calls.
Customer support service by UserEcho