Skip to content
Innovative Idea Exchange

Settings and activity

323 results found

  1. 30 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    An option to receive more than one notice type would be terrific for those patrons who rely on these notices to manage their account!

    We have so many patrons who have had either telephone notices or e-mail notices, only to see them inexplicably bounce or get blocked by some app or filter that they're unable to control or even aware of. It' becomes a paint point for frontline staff dealing with patrons who haven't received their notices & I think I've developed tennis elbow just from writing & rewriting the explanation of "INCOMPLETE LOGGED" in the Teleforms history.

    If patrons could elect to receive notices of more than one type, they'd have a failsafe, which is kind of how we're currently planning to promote text messaging, as we launch Vega Interact SMS.

  2. 8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    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
    Shawn P. Farrell commented  · 

    @Kathryn noted & voted!

    Shawn P. Farrell shared this idea  · 
  3. 18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    Yes, they're copy specific holds, but they're placed for a reason. We'd like to see this as well. Remain on the list until they're filled or marked missing or some other status that would prevent fulfillment.

  4. 11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    Some time ago, an idea was submitted to enhance the Sierra API to provide statistical group information, so that circulation transactions in third party applications could be credited to a statistical group other than 0 None.

    The idea won the "Let's Connect Sierra API Challenge."

    With the release of Sierra 6.0, it then became possible to include a new optional data parameter to specify the statistical group that should be used when recording a transaction performed using the APIs.

    My library was excited to hear this, as we'd recently begun using the self-checkout feature in the Bibliocommons' app not long before this & found it frustrating that credit for the transactions wasn't being assigned to a dedicated statistical group & just lumped into the default of 0 None. That Bibliocommons requires separate statistical groups for checkouts & renewals made it all the more frustrating.

    After some back & forth involving both Bibliocommons & III support & developers, we began seeing these transactions assigned the desired statistical group in Web Management Reports (see stat groups 908 & 909 in image bibstat1). This is enough to help those keeping track of metrics.

    However, this does not address the need of frontline staff who may need to see where an item was checked out. Normally, they'd do this in the SDA, by looking at the Checkout Location field in the item record.

    Unfortunately, this still displays the 0 None value (see image bibstat2).

    Apparently, this is because Bibliocommons does not currently support the username field in the API coding for their checkouts, which Sierra currently requires. In order for our library to take full advantage of our chosen app from its use to the resultant metrics, we're hoping that the stat group functionality could work without necessarily specifying the username.

  5. 6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    Our Acquisitions staff does not use List Price when ordering, & is hoping that Estimated Price could be modifiable via Rapid Update. At the moment, this would help them modify 200+ order records, which they now have to do manually.

    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    Our Acquisitions staff does not use List Price when ordering, & is hoping that Estimated Price could be modifiable via Rapid Update. At the moment, this would help them modify 200+ order records, which they now have to do manually.

  6. 7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    When creating a new customer record from scratch, or when updating & finalizing those submitted through our online application, we have staff perform some checks to prevent duplicate records.

    They'll begin by searching the Name index to make sure that there's no pre-existing record for the same name. Then as backup, they'll try searching by birth date or phone number.

    However, when you search by birth date or phone number, the results do not come back in alphabetical order, making things a bit harder than they should be for frontline staff. See example image where the search for the DOB of 05301988 brought back 24 results. Kind of a hassle to find who you're looking for, if not in order.

    While birth date & phone number are different indexes than name, can the results they retrieve be sorted alphabetically? If not, why not?

  7. 12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    Staff would like to see the ability to sort results retrieved from queries performed in Sierra's Search/Holds mode.

    Say for example they do a keyword search for Star Wars at our Forest Park branch. 124 items are found. The results are displayed alphabetically by default. But if the staff member wants to quickly sort by DVDs, they can't even click on the Format column heading, as it exists currently.

    While they can run multiple limits to narrow down the results by format, language, shelving location, publication date, etc., they might just as equally be inclined to SORT the entire list of results by one or more of those filters, or even something like author, & print & take that list to the shelves to find things.

  8. 22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  9. 9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  10. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  11. 7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  LX Starter  ·  Admin →
    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
    Shawn P. Farrell commented  · 

    CHPL would appreciate this as well, especially if the point at which old notices are purged can be determined by the library. Because of the volume of notices we send out & how long we've been using LX Starter, our performance metrics for configured notice jobs take a while to populate. Retrieving log data can also take quite a bit of time.

    Optimally, we'd like to be able to set the same retention limit for logs on all notice types, whether they're e-mail, phone, or print.

    Shawn P. Farrell supported this idea  · 
  12. 15 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  13. 24 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  14. 11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell supported this idea  · 
  15. 6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
  16. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
  17. 11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    The vendor payment address should be accessible at invoice payment function. Currently, the invoicing function needs to be closed & address information accessed at order record, vendor, etc.

  18. 12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
    An error occurred while saving the comment
    Shawn P. Farrell commented  · 

    I know its shocking when the subject of pop-ups in Sierra comes up that anyone would want "MORE!," but our Acquisitions staff would like to see a warning of fund spending over limit at invoicing in addition to ordering.

    Their rationale is that shipping & Mylar costs usually cannot be pre-determined. Once posting happens, the fund goes negative. Since there is no going back, like when you're about to go down the chute at the end of Splash Mountain, there should be a warning.

  19. 6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  · 
  20. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Shawn P. Farrell shared this idea  ·