Support Outer Joins at the Dashboard Level
Outer joins are in preview now but only to be supported at the modeling level, we need them supported at the dashboard level. For customers who's clients require self service capabilities, and do not have the ability to modify data models, this is critical functionality. In this case, not having this functionality will stunt the adoption and roll out of Sisense all together until addressed. Inner joins, at the dashboard level does not meet requirements, and is detrimental to the value of the solution overall. This is a huge blocker for rolling out Sisense to our customers.
Sort the values in filters
Currently the values that get displayed in a "text" based dashboard filter is sorted by default in ascending order. This is ok for most cases. But for certain cases (e.g. date as text) - we wish to showcase values in descending order. Hence, the feature request for allowing sorting in dashboard filters.GIT integration broken by slash in dashboard name
I called a dashboard "1. My users/clients". GIT integration misbehaves when I include this asset: I think dashboards "after" this one get excluded because the slash gets interpreted in some unhandled/unescaped way. Please either make GIT integration handle slashes, or prevent users from entering slashes as part of their dashboard name.
Report Manager SFTP Filename Format
When scheduling reports to be delivered to a SFTP through Report Manager, the files deliver however the filename is automatically being generated with a date stamped. As a report scheduling user, I want the ability to define how the filename will output, with or without a date stamp, so that the filename meets the needs of my configured pipeline processes.
User Specific Time Frame filters
The time frame filter on date fields is great, but the values in the list don't always meet the needs. We have needs for things like 31-60 days, 61-90 says, >90 days. whether that is forward looking or backward looking. This is easily done with the Advanced filter, but that is not easy for end users to use. It would be great if we could add these common filters. It would also be great if we could remove filters from the list that are not used in our environment. Finally some of our users would be better served by 0-45 days, 46-90 days vs the 30 day windows described above. This is why it would be good if users could create and reuse their own Time Frames. Note these time frames probably apply across dashboards for that user.
GROWTH function without hard-coded date filter
Add the possibility to use the GROWTH function without having a date filter on a dashboard or a widget level. End users building dashboards should not have to hard-code date filters to use these widgets. This limits our ability to adopt the Analytical Model which Sisense is investing all its efforts into, the Analytical Model behaviour should be consistent with compatibility mode.
Ability to more granularly control editing of Shared Formulas, Attributes, and non-shared Formulas
We embed Sisense into our application and produce pre-built dashboards for customers (which they cannot edit). We allow our users to create their own dashboards as well and with this comes the ability to create their own formulas. We have found that allowing them to edit the name of their formula also allows the editing of our pre-built shared formulas and our attributes. While this only impacts the user locally, it can become a support nightmare, as customers can rename our pre-built items and make it hard to them troubleshoot. We would like the ability to make these edit options more granular so that we can control (1) Shared Formula name edits (2) Attribute name edits and (3) non-shared Formula, local user dashboard, name edits.Shared formulas
**Please note this idea was migrated to the Product Feedback Forum from older submission areas** Designers cannot save formulas for shared use. This is problematic in two scenarios: 1. End users (our customers’ customers) are Designers 2. Data models are shared across multiple tenants (with row level security) Without this the customer is forced to either manage hundreds of separate data models, which is not sustainable, or to remove all ability to save formulas, which is not acceptable for users. The “Shared Formulas” feature should allow for permissioning; something similar to “limit sharing to users’ own groups” would work.
