Kurt Vollmerhause (QUT)
My feedback
7 results found
-
189 votesKurt Vollmerhause (QUT) supported this idea ·
-
47 votes
An error occurred while saving the comment Kurt Vollmerhause (QUT) supported this idea · -
30 votesKurt Vollmerhause (QUT) supported this idea ·
An error occurred while saving the comment Kurt Vollmerhause (QUT) commentedThis would be a useful enhancement, especially when the sandbox (whether standard or premium) is being used extensively for testing prior to implementation of a new service/product in the production environment.
-
70 votesKurt Vollmerhause (QUT) supported this idea ·
An error occurred while saving the comment Kurt Vollmerhause (QUT) commentedSupported, this is a key requirement.
-
19 votesKurt Vollmerhause (QUT) supported this idea ·
-
3 votes
An error occurred while saving the comment Kurt Vollmerhause (QUT) commentedWould testing in your dev (Sandbox) environment provide the same outcome?
Otherwise, in the production environment it is possible to add a role with an expiry date to ensure that it is only live for a set period (if adding a role temporarily for testing purposes) - or to quickly deactivate or reactivate a role via user management for that client (if trying to see whether removing a role will resolve the issue).
-
10 votes
An error occurred while saving the comment Kurt Vollmerhause (QUT) commentedAgreed! In addition, extending this to other Contact Info segments (including user's email addresses) would be highly regarded in order to avoid excessive manual input at the individual user record level.
Another use case is to add/update an existing personal email address to a generic 'work' email address, on a batch basis via Update/notify users job, prior to running a purge user records job. (That is, when the institutional Delete User Policy is set to Keep Fully Reportable, but it is _not_ desirable to include personal email details in Analytics in perpetuity)
Kurt Vollmerhause (QUT) supported this idea ·
Supported. The institutional delete user policy should be applied consistently, regardless of the method used for removal. There are often use cases in which it is inefficient to deploy the Purge Users job for only a single identified user record, or a small number of records, which might better be deleted manually. An example for our institution is the annual purge process for community cohorts such as alumni, which (from Analytics reporting) may well produce only a few candidates for removal.