In the forthcoming addition of ‘preferred surname’ field to Student Manager and Admissions Manager could the software please default the ‘preferred surname’ field content to match the content of the ‘surname’ field rather than being blank. Users to edit 'preferred surname' as and when a student has a different preferred surname.
This will preempt a lot of work by schools to populate this field retrospectively.
@Michele, I concur with Joanne's note.
Whenever iSAMS add a new field (or as in this case bring an field that has existed for some time into use), full consideration should be given up front as to how and when that field is be populated. Earlier this year we had a handful of new fields added to both pupil and staff records that were required by the census routines but had been given no default values, which forced schools to manually populate the fields for hundreds of histioric records just to be able to run the census exports.
In this particular case, I consider that making the preferred surname (where empty) the same as the legal surname would be a sensible default for the overwhelming majority of cases, which would allow simple reports and exports to proceed with the new field without having to add logic to handle the empty 'preferred surname' case.
Hi Michele,
Thanks for your email. I agree, for SSRS reporting I would check Preferred Surname first and, if blank, then revert to Surname.
The reason I requested ���Preferred surname��� duplicated from ���Surname��� as an initial default (with manual override then allowed) is because, in past experience, on introduction of a new field sometimes assumptions and dependencies on it being populated have been incorporated into iSAMS software too. I���ve found that there can be loosely associated errors flagged up by iSAMS software where a new field is blank/unpopulated in student records which pre-date the introduction of the field.
While we can pre-empt this on the introduction of new students into iSAMS by ensuring that the field is always set explicity (ie.not blank/undefined), it can be more problematic for us for the set of students on record prior to the introduction of the new field. Retrospective action has to be taken to populate the new field and this is not always straightforward when the new field hasn���t been introduced to the Export Wizard field set and/or to the fields available for group/batch edit. It���s essential that the new field be made available in the Export Wizard. To identify the students affected I can use a direct query but this isn���t something that the school office team would be able to do themselves. I���ve just rechecked and ���Preferred Surname��� isn���t yet available to export ��� see screenshot below.
Similarly, although not relevant here for the surname field, introduction of new fields without concurrent introduction as an option in the group/batch edit functionality also incurs considerably more work for the team as each student must be amended individually. You���ll see I submitted requests for Export Wizard and Group/Batch Edits on the Ideas Portal.
Hope this clarifies why I was hoping to have ���Preferred surname��� duplicated from ���Surname��� as an initial default but do let me know if I can provide any further information.
Kind regards,
Joanne
[cid:image001.png@01DA9A19.A0708700]
HI Joanne,
I'd like to get a better understanding as to why you are suggesting this default. We are currently looking at an option to pull in the Preferred Surname into search results, etc only if it is populated, and if not populated, to use the Surname field.
Thanks.
Michele