Please Share your Product Ideas with us!

1.  Security should be based on the Wave / Process Area / Object Key in Security Definitions.  If you have permissions to see an Object, then you can see all the Reports for that Object.  Currently security is assigned in the Console / Elements / Object screen which is not intuitive, and can be overwritten at the Target Level or the Report level (I think?).   Not sure which Target screen (Target Design?)

2.  There should be a very direct, simple interfaced to add/remove users from the Wave/ProcessArea/Object Key, ideally outside of the Admin / Security module. 

          a.  Need two screens, User (Objects), and Object (Users). 

           b.  Should have a * option to quickly add user to ALL Objects, or ALL Objects for a Wave/ProcessArea.

           c.  Roles provide an awesome way to add users into lots of Keys, but in the case of Objects the security is often slightly different for each Team Member.  So adding a user to a "Validator" role will give them most of their security, we would probably want to assign specific Wave/ProcessArea/Objects to each user individually. 

          d.   Ideally the same Wave / ProcessArea / Object security could also be used for DCS Screens

         e.   Should also provide a simple Summary Report of Users access since this is often requested by Auditors

3.  Individual Reports should be easy to Publish or Unpublish to the reporting tool.    Which reports are published will continually change over time, and we need to be able to "Unpublish" a report very easily.   The check box on the Report should only indicate if that report is "visible" or not in the Reporting Tool.    Use the flags at the Target and Object level to determine whether or not to "refresh" the reports in the Reporting tool.

4.  Allow the ALL reports screen to be added to the QuickLinks by default.  Currently only the QuickReports link is available.

5.  New users should default to the ALL Reports screen since they won't have published any QuickReports yet and may not know how to use DSP very well yet.

6.  The Reporting screens should not be limited by the Context Menu.   Let the users see all their Waves / Process Areas / Objects on a single landing page so they can get a quick overview of all their assigned objects without having to keep switching contexts.      Security for the objects is still derived from the security keys.

7.  Give the Reporting Screens a better Marketing name since this will be the PRIMARY interface for MOST of our users.    MOST users on a migration project only use DSP for Reports, DataConstruction, and maybe dDup.    We need a catchy name so we can tell new users to "Go into ReportTrack and review your errors"  (or some other name that sounds cool)

8.  Allow reports to be accessed from other Environment   (See 3M or DOW implementation of ReportTrack)   In a multi-tier or Multi-server environment, it really difficult to manage user security across the landscape.   By allowing Reports to be centralized on a single instance (along with DCS and dDup), we can confine all the Business Users to a single box which makes the Security MUCH better.   Only the DataMigration team need access to all the various boxes across the landscape.

9.  Provide an options to turn OFF / ON ALL reports at the Object Level.    If the project cadence is to Process ALL objects on Sunday Night, then once done all the Reports should be turned off (at the Object level) so when the developers start working Monday morning and testing their targets the reports are not updated in the Reporting Tool.   Developers would know they have to turn it back on if they needed to publish the reports, but this allows the reports to remain stable for the week while development continues.    A single button is easy to use to Turn On All Reports /  Process all Objects / Turn off All Reports.