The desktop version of Maximizer enabled the user to view 'tiles' of the Company/Individual/Contact record in the Address Book with User-defined fields, (other) Contacts, Notes, Documents, Hotlist, and an Outlook display -- all in one view, without switching screens.

As you know, the Maximizer LIVE screen enables the user to see the Address Book data and User-defined fields, and EITHER the (other) Contacts, or Notes, or Documents, or Hotlist, with no view of e-mail.

I've gotten used to this limitation, but I would be able to work much faster if the lag-time between switching screens between Contacts, Notes, Documents, Hotlist, and the Outlook e-mail screens could be minimized by a single view of all these functions.

In most cases, the "allow public entries" is really limited to whether the user can create public Address Book entries or not. However, I think the concept is more granular than that.

I want users to be able to create public Address Book Entries, Notes, and Documents - but for the vast majority of users, I do not want them creating public Column Setups / Search Catalogs / Email Templates / etc. Often times, users will create these items without realizing what the implications are and it leads to clutter across the program. Certain users (department heads, admins, power users, etc.) should be allowed to create public objects which are shared across departments as required - but it would be nice to prevent users from inadvertently cluttering the database with public stuff while still giving them the ability to create the public objects that they should be creating.

When a user stops working for a company, most people will delete that user ID from the database. However, by doing so, the user is no longer available and stops showing up in various search functions (Case Owner, Opportunity Team Leader, etc.). For historical reference purposes, it would be good to keep the User ID around. However, doing this results in the various Column Setup / Favorite List / Coloring Rules / Search Catalog / Dashboard / Email Template / Action Plan screens becoming cluttered with data of users that no longer work for the company.

There needs to be an "archive user" feature which will clean up all of these personal objects from the database without removing the user from the list of users. This would allow the best of both worlds - to have the user available for historical searching / reference purposes without continuing to clutter the UI with the objects they made for themselves.

When administering a user in the Web Access Administrator, there is no way to quickly remove a user from all of their Group / Team memberships. Each box must be clicked (which triggers a postback) and then the Remove button must be clicked to execute the operation.

In the Windows Administrator, the list item could be double-clicked to remove it - or ALT+R could be used for even faster performance. The Web Access Administrator is too inefficient when working with a large number of users on a large number of Groups / Teams.

Since ALT+R would not work in a web browser, implementing "Remove All" and "Add All" would be a decent compromise that would save significant amounts of time.

Currently, user / group permissions control access to the "Address Book" as a single entity. However, there are frequently cases where the permissions need to be more granular than this.

For example, a customer has no use for the concept of "Individuals" and they want to prevent users from inadvertently adding this kind of record into the database. Currently, the only front-end solution is to deploy a MenuBuilder customization which removes all references to "Individuals" from the various record creation menus.

Ideally, this should be handled by separating the user / group permissions into buckets for:

• Company


• Individual


• Contact

Business logic would be used to ensure at least Company OR Individual was selected - because a Contact must be attached to a parent-level record. Additional thought might be given to expanding this to include the old-style lead (starred) records as this was also a common request in the past.

This needs to be added to the Administrator module. There is currently no way for an administrator to review the Default Entries for the users.

In the Windows Access application, an option to "View Default Entries" existed for each of the modules, but this does not exist in the Web Access application, nor is there any way for the Administrator to review and alter Default Entries without being logged into Web Access as the user in question.

In an on-premise deployment, this can be easily done via SSMS, but that's obviously not an option in CRM Live.

We need to be able to:

• View all Default Entries for all users for a given module


• Configure the columns which are displayed


• Make changes to individual Default Entries


• Recreate a Default Entry which might have been deleted in the past.


• Perform a Global Edit on all Default Entries within a module

Additionally, Default Entries need to be expanded to define:

• Active Column Setups


• Active Key Field List


• Visible / Invisible following tab states

Nearly every Maximizer database I've seen does not correctly implement group-level permissions. Instead, permissions are a mixture of user-level permissions and group-level permissions. Trying to clear all user-level permissions to go with a 100% group-based security structure is a nightmare because each user has to have their user-level permissions manually un-checked. There is no easy way to quickly clear all user-level permissions.

In an on-premise world, a SQL trace could be executed and reverse engineered to clear these values directly in the database, but the user tables are typically the most complex to interact with manually and updating the columns might have unintended consequences. In CRM Live, that's obviously not even an option.

As simple UI enhancement would go a long way to making user administration much less of a nightmare.

The Contact # field isn’t available in a column layout so it’s not possible to export a list of existing Contacts to then match to your new CSV data to be imported (using VLOOKUP for eg) to provide the Contact Number field for importing which is required for matching along with the Identification field.
The Import functionality is lacking in a few other aspects as well which is a pain in real-world usage as they really make life difficult :
- Table type UDF’s use to be able to be populated by the import process, but this no longer happens. It either needs to be reinstated as a feature, or another type of Import option should be provided just to allow import of a csv into a table UDF
- When manually adding new Table UDF items there needs to be a keyboard shortcut for adding a new one eg the + sign perhaps as otherwise it’s a case of swapping back & forward from typing the value, enter to save it, then mouse to click on the add a new one option – annoying
- When you save an Import Template it’s only visible to the current user, so they need a security feature (like everywhere else does ie this is inconsistent) so that you can make it available to Public, or a Group
- – the Opp Stage & Status are unavailable for Import. AND, neither are available in the Global Edit either
- And last but not least, there needs to be a CSV Import option for Cases!!!