Skip to content

Kurt Vollmerhause (QUT)

My feedback

7 results found

  1. 189 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Under Review  ·  13 comments  ·  Content » other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kurt Vollmerhause (QUT) supported this idea  · 
  2. 47 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Kurt Vollmerhause (QUT) commented  · 

    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.

    Kurt Vollmerhause (QUT) supported this idea  · 
  3. 30 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kurt Vollmerhause (QUT) supported this idea  · 
    An error occurred while saving the comment
    Kurt Vollmerhause (QUT) commented  · 

    This 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.

  4. 70 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kurt Vollmerhause (QUT) supported this idea  · 
    An error occurred while saving the comment
    Kurt Vollmerhause (QUT) commented  · 

    Supported, this is a key requirement.

  5. 19 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kurt Vollmerhause (QUT) supported this idea  · 
  6. 3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Kurt Vollmerhause (QUT) commented  · 

    Would 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).

  7. 10 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Kurt Vollmerhause (QUT) commented  · 

    Agreed! 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  · 

Feedback and Knowledge Base