Hi, all! First-time poster here. We’re brand new to Dundas and starting to build some of our first reports. As we dig more into it, we’re thinking that some sort of naming convention for dashboards and the metric sets/reports that make them up might help to organize everything. Does anyone else use a method like this and would you be so kind as to share it with me? Also wouldn’t mind hearing from users that tried this and then decided it didn’t work or was unnecessary.
Thanks!
-Ryan
Hi Ryan, Welcome!
I’ve found that when building a lot of dashboards, even with good naming, it becomes unorganized. People will simply forget names. I’d highly recommend using folders or projects to group your dashboards into reasonable categories. At least with simple folders, you would not have too much content in each and things would be reasonable to find.
Just please don’t do this:
Also - if you use our home screen you can apply favorites which will make the naming conventions less important once your users find content they like.
https://www.dundas.com/Support/learning/documentation/get-started/using-the-home-screen
Hi Ryan,
Welcome to Dundas family. I would suggest to create Folders under Dashboards/Reports naming them as per your Projects such as Marketing, Production etc. Also, I would create a Draft Folder for each of these projects because while working on your reports/dashboards you might be tinkering with new ideas or approaches to present data. Keeping drafts separate from Final Dashboards/Reports will come in really handy if you need to revisit some of the earlier tried ideas. That’s my 2 cents.
Definitely agree with @ravi.bansal, you will probably need multiple versions of the same project or folders within. We have a ‘live’ and ‘dev’ version of most projects.
We work for external clients so the project name is the client name and then project. Internal projects are prefixed with a ‘Z’.
Dashboards are named for the name of the dashboard (home page, top line KPI page etc. etc.)
We use different folders if there are many things and then divide them into sections. Generally though, we don’t have too many dashboards in a project so it is not necessary.
Wow, thanks, guys! These are super helpful replies! Sounds like folders and projects are the way to go here for sure. I’ll pass this along to my team. I’m sure you’ll be seeing me more around these parts though. 
Only thing I have to add is I use DEV_Project and PROD_Project. When I have worked out the changes to existing then I publish the changes and this way if i check in something to test it out the users do not get errors or keep seeing changes until I am done tinkering around.
I also use Projects First to separate Categories of Dashboards then inside that I use Folders to group things together. I like the Idea of having a test folder, I just use the main folder and then move it to a the right sub folder for this idea.
I always make my metric Sets as a Metric set before putting them on a Dashboard. When I took over the Dundas Dash-boarding I inherited a lot of auto generated metric sets that needed some tweaking or I just need to see how they worked and with them all being auto generate with auto naming it was horrible.
DO NOT make a dashboard with all/any auto generated metric sets you will regret it later.
There are a lot of names to change, the display name and script name (maybe one day Dundas will auto change the script name when you change the display name), then Filters have names (display and script) and those connect to ViewParameters and they all get auto generated names and you need to be diligent in naming them all so they make senses to what they are or else you will get lost very quickly.
I love all these ideas, and I think everyone is right about folders. Another thing we do here is specifically create a reports dictionary in excel (though there’s no reason we couldn’t move this to dundas eventually). We are using SQL server and get TONS of report requests here all the time and have multiple hands touching one report in process, and are in the process of moving everything over into dundas. So we have a spread sheet listing dashboard name, data cubes / connectors it’s linked to, views/tables it’s connected to in SQL, whether it’s been QA’d, and when it’s scheduled to go out. This way the people involved in reporting who are not yet in Dundas can also see these things if they need to. Inside of Dundas each of our projects has a report folder so that all the reports are in one specific location, separate from the other dashboards, For a lot of our reports we actually just use a dashboard with a table on it and auto export it to people, and then if there is a team that has tons of reports as we bring them into Dundas, there will be a dashboard they can access that links to all of their reports and organizes them in one place as well. For the end user it’s really helpful for reports to be connected to some “main” dashboards and to eventually set up some navigation between those dashboards too, if that makes sense, so that they’re actually clicking between file lists as little as possible and have a little easier flow of an experience, and then people in Dev can use these interfaces too! Hope that’s not too wordy! I love thinking about organizing our projects and making things as easy to find as possible
I prefer Using Folders along with any naming convection you will use
I’d love to see the following:
As for names…I use a three letter prefix, especially in front of dashboards and templates since they are curiously in the same folder and I want a way to identify them uniquely.
These add-ons would give us the ability to bypass the built in Dundas sort mechanism, give us an ability to easily look for files of our own type, and sort files by tag value so that we can create our own hierarchies.
Thank for considering my thoughts…
PS: Being able to right click an asset and produce a dependent tree would be sweet too.
Buck
Right click -> properties -> references will produce a dependence tree
Hi Buck,
As for,
Attributes that allow us to tag assets with common and searchable and sortable self-defined names
This can be achieved with Tags. Below is an article introducing Using Tags,
LINK: https://www.dundas.com/Support/learning/documentation/share-collaborate/file-and-folder-properties#h3-1-using-tags
I actually just completed a project to completely re-work the objects within Dundas which (when I inherited it) were named ad-hoc and in only a handful of folders.
For data cubes, I took the technical route since only Dundas-savvy people in my company will be changing much at that level. I built folders first by source (since we pull data from a half-dozen systems each with their own data connector), then made sub-folders to indicate what step along the data path the cube exists. For example, cubes that pull directly from the data connectors have their own sub-folder, cubes that filter/process that data have a 2nd folder, cubes that process PROCESSED data have a 3rd folder, etc. It’s daunting to look at at first, but really saves my time when I’m tracing data back up-stream AND when I’m trying to figure out if I already have an existing cube that does what I want it to do.
For metric sets, I flipped over to an end-user perspective. Again I have my first level of folders based on the source of the data, but then I built folders based on what’s actually being displayed - data label for something that returns a single number, table, histogram, etc.
Finally, for dashboards I put them in folders based on their primary usage. It doesn’t always work as dashboards are versatile, but it does the job for the most part. (Wallboards for dashboards we have on screens around the office, Reports for dashboards that are e-mailed on a schedule, etc.)
Beyond all of that, the best advice is to ask yourself if the name describes the content to someone that just walked in the door. When I’m training people on our Dundas environment, I bring up the example of MSCountNetworkingTicketsEnteredYesterday. Yes, it’s a long name, but it tells me everything. It’s a metric set (a habit I picked up from VB coding), it’s a count, it only looks at Networking Tickets and it only looks at Date_Entered of Yesterday. Clear as mud. 
Don’t be afraid of a long name if it takes 6 or 7 words to describe what’s happening.
Best of luck!
