Data Polishing for Inquiries and Applications (automatic data formatting)
Because we care about consistency and formatting when communicating with our constituents, our Admissions staff need to retype many names, addresses, and phone numbers that are submitted via our online Inquiry form. We are currently using a third-party application process because it does a good job of automatically "polishing" or reformatting names, addresses and phone numbers. It would be exceptionally helpful if your Inquiry and Application handlers included or allowed for some basic data polishing.
This would
include forcing names and addresses to title case, expanding
abbreviations such as St. and Ave., and the ability to reformat 10-digit
phone numbers according to a selected pattern.
-
Cedric Paine
- Jul 22 2015
- Under consideration
-
Nov 23, 2015
Admin response
This is under consideration as part of a User Management project for data formatting.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +486
-
Data validation: Require phone numbers to be entered in a chosen format, e.g., (502) 897-2785 or 502-897-2785
Merged Restrict all phone number fields on the application to a certain format including dashes, e.g., (502) 897-2785 or 502-897-2785 and make the phone number field for the candidate a required field. There should be data validation on other fields, lik...4 Under consideration
-
Form field validation options
Merged Please add the ability to control input for fields in the forms. Allowing people to enter free text creates an incredible amount of data clean up work that could easily be avoided by supplying a few options. For example allow "Titles" and "Suffixe...1 Under consideration
-
Add the ability to use a mask for different phone types (applies to all on products not just onBoard)
Merged Currently parents can enter a phone number in any format (or none at all) necessitating us manually correcting the phone number into the (xxx) xxx-xxxx format (for example). EE has masks that can be assigned to various phone types. It would be ext...0 Under consideration
-
Phone number formatting
Merged As a Platform Manager, I would like the phone number fields in the onBoard inquiry and application to be limited to accepting numerical characters and dashes only rather than accepting alphanumeric input. Currently, if a student does not have thei...0 Implemented
Related ideas
This idea has been under consideration since 2015, any updates to this much needed feature? Too much time is spent validating and reformatting.
Terrific idea!
This is very important, but it is also important that we have control over how it should format! Do not assume that all schools prefer "Street" instead of "St" or phone numbers that use all dashes instead of parentheses. We need to be able to set these preferences
This is ridiculous that this basic coding has not been done on these customer (parent/prespective parent) forms. Blackbaud really ought to be ashamed of the lack of attention to detail here.
It is very disappointing that this suggestion initially made on July 2015 has not yet been implemented even after it was considered in November 2015. As a large SIS database vendor, data accuracy, data validation, data conditional formatting, should be the top priority when it comes to data integrity. Otherwise, it's just garbage in garbage out (GIGO).
Please have your engineers/developers put this on their high priority and get it done!
Yes yes yes! Please implement this! Suggested since 2015, 549 votes (!!)...
This should also clean up extra spaces... auto-complete on mobile devices very often leaves a trailing space that shows up when you export lists for things like printing award certificates, programs, or diplomas, and can be very time consuming to clean up manually.
There should also be some standardization for formatting of hyphenated and non-hyphenated compound Given and Family Names, preferably with options for how names are stored, how they're exported, and how they're displayed in profiles/on reports like report cards.
This is a very long time coming!
Agreed - Forcing a format ensures a consistency that is helpful in multiple ways.
We would make use of this feature if/when implemented.
Can't believe we are still voting on this. How difficult is it for Blackbaud to write code to format phone numbers?????
Here is the issue -- we care about consistence; Blackbaud however does not. I'm so exhausted from the constant cleanup that has to be done for something that would seem so incredibly simple.
This has been under consideration since Nov. 23 2015.
It would be helpful if the phone number field can be intuitive enough to shift its formats according to "country", i.e. when United States is selected then it automatically makes the phone number format to (xxx)-xxx-xxxx, but when any country other than United States is selected then it would reverts to a blank field that can accept any format of phone numbers. Currently it seems to only default to (xxx)-xxx-xxxx no matter what country is selected.
We'd like to be able to chose the format of phone numbers that we want in our database. Right now we have a mess, 5,000 + users with one format and all new users added through admissions with another. If we could choose the format in the admissions application and inquiry form we could have incoming users' numbers match the format currently in use.
YES!! I have international families who don't understand the question and list "Samsung" as their phone number and it's ridiculous that Blackbaud is fine accepting this. Or who enter only the first part of their email address with no @ or .com/.org/.edu.
Likewise, on Event Registrations people can enter whatever they want. Nonsense years (obviously an applicant wasn't born in the year 210), names of just a ?, etc. And then we can't process the form, so Blackbaud will gladly accept unusable data but then leaves us to try to figure out how to correct it, which we usually can't if the phone number and email are both unusable. If the user could be prompted to correct, it would be so much better.
Would be nice to have some data validation in "on" products! Just sayin'
This would be helpful on all forms, not just inquiries and applications. If we want to do a profile update form, there would be over a thousand responses that would have to be manually reviewed for errors that could be prevented with simple validation.
Alternatively, allow admissions staff to edit the data as it is processed into Enrollment Management!
I know this feature would be very helpful with our RE connection