Automatic import of data into Student Enrollment

On this other duscussion we were talking about allowing for more customization on the application forms.

An alternative approach to changing the built-in Application form in Gibbon would be to use our own form builder or system of collecting all the pertinent information and then importing it into Gibbon. Is there a way to automate the import process? Even some sort of hack? Many of these open source form builders have the option of dumping straight into MySQL but we would need it to tell Gibbon a new record was created at the same time.

Alternatively we could setup one of these open source form builders in another space on our server and then create a script which would import the data automatically to Gibbon after a submission. I know this is more of an API type of feature but what would you recommend for auto importing our data?


Hi jemmyn, Gibbon has a set of built in import scripts, which you can access (for user imports) under Admin > User Admin. In addition, @ross has created a wonderful tool called Data Admin that does very flexible imports, as well as a host of other tasks, and which can be downloaded from our Extend page. I hope this helps! Ross.

I did see those import tools… I will look into automating them or using @ross tool. Thank you very much.

@jemmyn @ross @rossdotparker @admin I too need to import all the student data collected in the application form into gibbon. I have them in a csv file…however data admin only allows a partial import of students and full import of users information which means I can’t save parent information…please let me know if you found a solution…thank you

There is a 3rd party Module called Data Admin we installed and are using to import our information. Even with this though we are finding it fairly cumbersome to import the data we need. We have imported the data but we are having to still manually assign role groups, class of, etc… We specify some of these things in the import and its just not coming through as expected.

Im working on a plan to develop a more sophisticated form builder which would allow us to create custom forms inside Gibbon rather than building a custom form and then trying to import the data. I am willing to put some money and resources into it to get it working too. I will need some assistance from Gibbon staff. Ideally it will be a module with an open source form builder like: - My team will probably start working on this at the beginning of the year. Let me know if you have any input for this or want to contribute any $$$ for dev.

There sound like there are some interesting developments afoot, and we certainly welcome news of possible module construction. In terms of contributing funds, we are still working on getting a non profit body set up to fund raise, and so don’t have funds to contribute at this time…but one day this is the kind of thing we hope to be able to support. For now, we can answer questions at least!

One option on the import front is building new templates for @ross’s excellent Data Admin tool: I believe you can then contribute these back to her so that they are available for others to use. However, I wonder why you would want to import application forms at all? Why not just import user, family and enrolment data?

Thanks and good luck!


Our issues is that we can not figure out a good way to connect the separate data imports.

To break it down we have a large enrollment application that asks some of the questions Gibbon application asks but also a bunch of other things (health information, payment schedules, etc…) When we try and take that data and import it into Gibbon only some of it can be automatically connected. For example, because of the way we collect the data from parents, I have not figured out a common identifier between user and family. So userA, userB, userC can not be connected unless we have a multiple import processes.

It would make much more sense to use the built-in application but since it asks a bunch of stuff we don’t need and is missing a bunch of stuff we do need its a little tedious.

Also there should be a way to require the user to go to Data Updater before they continue after the rollover process. Each year we need to confirm the users information is updated and accurate. But if I understand correctly the only way to do this now - is to ask the user to click on Data Updater. If they don’t, we have no idea if emergency contacts have changed, health information has changed, parents have separated, etc. There needs to be an easy way for a parent to review this information and update it with a few clicks or just confirm that its all still accurate.

I want to build a form builder for Gibbon that allows us to choose what is on the application and hide fields that are not necessary, also an easy way to add more fields, include family info, health information, etc… Then also make this same form builder available for the Data Updater with a type of unique URL that would allow parents to receive a link in their email that goes straight to the data updater and requires them to update the data before they continue.

Hello again,

In terms of connecting imports, you can just assign arbitrary connecting codes (using a system of your own choosing). Gibbon refers to this as the Family Sync Key. It is not needed in the User import, just in the Family import. As long as matching appears in all three of the files in that import, then the users are connected into families:

In terms of a form builder, this would be a great addition to the project. We made a small step in this direct with custom fields for users, which appear in Manage Users, and optionally in application forms (student and staff) and Data Updater. Have you used this fields? This does not address removing fields, but does address adding fields, if building an entirely custom form. You can find these under Admin > User Admin > Manage User Custom Fields.

Having parents automatically pointed to Data Updater after the rollover would be great: we currently ask parents to do this via an email, although it is not as effective as we would like. Would this be something you could build in as an option to the core, and commit for others to use?