Import Completed Applications
Moving to Ayuna from another system — Keystone, a homegrown database, or a folder of spreadsheets — usually means you already have partner families whose applications were completed and approved long ago. Some are mid-build with sweat equity hours already earned.
You do not have to ask those families to fill your application form out again. The import brings their applications across as finished records, so they can sign in to the Homeowner Portal on day one.
Before you start
- Set up your application form. Go to Administration → Homeowner Settings and choose an active application template. The import sheet's columns come from the questions on your form, so this has to be done first. If you have not built a form yet, make a copy of a default template under Form Templates, adjust it, and publish it.
- Decide whether your families are already in Ayuna. You do not have to add them first. Each row is matched to a constituent by email, and a family with no match is added as a new constituent from the name you give on the row. If you are also migrating donations, volunteer hours, or full contact details (addresses, birthdays), load your contacts through Administration → Data Migration first so each family ends up as one complete record.
Step 1 — Download your import sheet
Go to Administration → Homeowner Settings and find the Import Completed Applications card. Click Import, then Download import sheet.
The workbook has three tabs:
- Instructions — a reference for every column, including the exact answer choices your form allows.
- Applications — one row per family. This is the main tab.
- Sweat Equity — optional, for hours already earned.
Constituents who already hold the homeowner role and do not have an application yet are pre-filled into the Applicant Email column, so in many cases your roster is already there and you only need to fill across the row.
:::caution Constituents without an email address This import matches applicants by email only. A constituent imported with a Contact ID and no email (the recommended form on the data-migration Contacts sheet) will not appear in the pre-filled roster and cannot be referenced here yet. Keep a real email on file for anyone who may become a homeowner applicant, or add one to their constituent record before running this import. :::
Prefer to work in CSV?
There is an or download as CSV option next to the download button, and the
upload accepts either .xlsx or .csv.
The Excel sheet is the better starting point — it is the only one that carries the instructions and the answer dropdowns — but if your data already lives in a CSV tool, the CSV has exactly the same columns as a plain header row.
Two things to know about CSVs:
- A CSV holds one table. Upload your applications as one file and your sweat equity hours as a second file. Ayuna works out which is which from the column headers.
- Keep the header row exactly as downloaded. Your columns are matched by name, so a renamed heading will be ignored rather than imported. Extra columns of your own are fine — the preview tells you which ones were skipped.
Saving from Excel as "CSV UTF-8" is the safest option if any of your families have accented characters in their names.
Step 2 — Fill it in
Orange columns are required, green columns are optional, and blue columns are your own application form's questions.
Only these four are required:
| Column | What to put in it |
|---|---|
| Applicant Email | Matched to your existing constituents. If nobody has this email, a new constituent is created |
| Application Date | The date the family originally applied — not today |
| Status | approved, in_progress, completed, or rejected |
| Household Income | Annual household income at the time they applied |
Families who are not in Ayuna yet
If an applicant's email does not match anyone in Ayuna, fill in Applicant First Name and Applicant Last Name (and Applicant Phone if you have it). The import adds them as a new constituent and attaches the application to them. Before you confirm, the upload screen tells you how many new constituents it will add.
These name and phone columns are only used for new people. If the email matches someone already in Ayuna, their record is left as it is, with one exception: a constituent who has an email on file but no name gets the name from the sheet.
Ayuna only matches by email. If a family is already in Ayuna under a different email, the import would add them a second time. When a new applicant has the same name as someone already on file, the upload screen warns you before you import. If it is the same family, change the row to use the email Ayuna already has.
You do not need complete data
Every other column can be left blank — including questions your application form marks as required. Those apply to families filling the form in, not to records you are bringing across from somewhere else. Only the four orange columns carry an asterisk, and they are the only ones the import insists on.
An imported application with blank answers is not a broken application. It appears in Ayuna with its progress shown — "4 of 12 questions answered" — and either your staff or the family can fill in the rest at any time from the application page or the Homeowner Portal.
So import what you have now and finish it later. That is usually much faster than holding the whole migration until every field is chased down. Before you commit, the preview tells you how many of your rows still have unanswered questions, so you know the size of the follow-up.
A few things worth knowing:
- Status only offers finished states. An application still moving through review should be entered normally so its decisions, dates, and applicant emails are real.
- Rejection Reason becomes required when you set Status to
rejected. - Legacy Application Number keeps your old system's reference number, so you can trace a record back to where it came from. Leave it blank and Ayuna generates one. Stand-ins like "Unknown" or "N/A" count as blank. Each number must be unique within your organization, so two rows with the same number are flagged, and so is a number one of your existing applications already uses. Other organizations' numbers don't matter.
- Source System — put "Keystone" or whatever you moved from. It is recorded in the application's history.
- Dropdown columns accept either the answer choice or the label the applicant saw, so you can usually paste straight from a legacy export.
- Multi-answer questions take a comma-separated list, e.g.
Ramp, Grab bars.
Dates
Date columns are pre-formatted, so typing a date into one and letting Excel
format it is the safest approach. If you are pasting text, use YYYY-MM-DD
(2021-06-14).
A date cell under a question your form asks as plain text (for example a
"Certificate of Occupancy" question) is stored as the date alone, like
2025-09-29.
Slash dates are read month first, US style — 03/09/2024 is 9 March 2024.
A date written day-first, like 13/09/2024, is rejected rather than guessed
at, so you will be told to fix it instead of ending up with the wrong date
silently stored. If your old system exported day-first dates, reformat that
column to YYYY-MM-DD before pasting.
A few checks catch the mistakes spreadsheets usually produce:
- Application Date, Decision Date, Closing Date, and sweat equity Activity Date cannot be in the future — they record things that already happened. Loan Maturity Date can be, since most loans run for decades.
- Decision Date cannot come before Application Date, and Loan Maturity Date cannot come before Closing Date.
- Dates before 1900 are rejected, which catches a mistyped year and the blank cells Excel sometimes turns into 1899 dates.
Questions on your own form that ask for a date — a target move-in, say — can be in the future. Only the columns above are restricted.
Loan and property details
Six optional columns hold the staff-only loan and property facts described in Track loan and property details: Closing Date, Loan Term (Years), Loan Maturity Date, Property Type, Year Built, and Ownership Status. Fill them in for families who have already closed so reports on existing loans work from day one; leave them blank for everyone else.
Property Type and Ownership Status are pick-lists. The sheet offers a
dropdown of the stored values (single_family, owner_occupied, and so on),
and the upload also accepts the labels shown on the Instructions tab, such as
Single Family Home or Paid off. Anything else is reported as an error with
the valid choices listed. Loan Term (Years) is a whole number of years, for
example 30, and Year Built is a four-digit year.
These columns import whether or not the fields are switched on in Homeowner Program Settings; switching them on is what makes the values visible on each application's detail page.
Imported applications arrive without a document checklist or education requirements. To give an imported application that is still open the requirements in your program settings, open it, click Edit Requirements, and then click Apply program settings. See Change one application's document and education requirements.
Sweat equity hours
Fill the Sweat Equity tab if families have already earned hours. Each row needs an applicant email, a date, a number of hours, and an activity type. Imported hours arrive already approved and count toward the family's requirement immediately.
Step 3 — Upload
Back on the Import dialog, click Choose file and select your saved workbook. Ayuna checks it and shows you what it found before anything is saved: how many applications are ready, how many sweat equity hours, and a list of any problems.
Nothing is imported until every row is clean. If there are problems, fix them in the spreadsheet and upload again — you will never end up with half your families imported and no clear picture of which half.
Common problems and what they mean:
| Message | Fix |
|---|---|
| No constituent found with email … | Fill in Applicant First Name and Last Name to add them, or correct the email if they are already in Ayuna |
| … already has an application in Ayuna | Remove the row, or edit the existing application instead |
| Status … cannot be imported | Use one of the four finished statuses |
| Your application form has changed since this sheet was downloaded | Download a fresh sheet and copy your data into it |
When everything looks right, click Import.
What happens to imported applications
- They appear in Homeowners → Applications at the status you gave them.
- Each one records that it was imported, rather than showing a made-up trail of review steps that never happened.
- Families get the homeowner role and can sign in to the Homeowner Portal.
- No emails are sent to applicants. Nobody is notified about a decision from three years ago.
What is not imported
Document acknowledgments. If your form asks applicants to open a document and confirm they have read it — a fair housing notice, a certification, a consent — those questions are left off the import sheet on purpose. They record that a specific person opened a specific document at a specific moment, which is not something anyone can fill in on their behalf. The Instructions tab lists exactly which of your questions these are. Collect them in the Homeowner Portal after importing.
Uploaded documents. Pay stubs, tax returns, and other files from your old system are not part of the import. Add them to each application under its Documents tab once the applications are in.
If your form changes
The import sheet is tied to the version of the application form it was built from. If you publish a new version of your form after downloading a sheet but before uploading it, the columns no longer line up — Ayuna will reject the upload and ask you to download a fresh one. Copy your data into the new sheet and upload again.
Having Ayuna support set this up for you
During onboarding, the Ayuna support person assigned to your affiliate can build your application form and run this import for you, instead of you doing it yourself. They use the same form builder and the same import sheet described above, and the import follows the same rules.
They can do this only when their assignment to your affiliate includes form access. Ayuna's support managers have it from the start of an assignment; other support staff have it only once a manager turns it on. Either way you can see it and turn it off, as described below. With form access on, they can:
- create and edit application form templates, and publish new versions,
- choose which form is your active application form,
- import completed applications from a sheet, and
- turn your existing form responses into applications.
They cannot change any other setting, and they cannot send your form to applicants by email.
Even with form access on, a support person can only make changes during a one-hour editing window. They open it with a stated reason, and it is recorded in your audit log. Their access to your account also ends on its own after 30 minutes of inactivity, or after 8 hours at most. Every time form access is turned on for a support person, that is recorded in your audit log too, under the name of the manager who did it.
Seeing and turning off form access
Go to Administration → Support Access. The Access column shows who has Forms & application import access. Admins who can manage users see a Turn off button next to that access. Turning it off takes effect right away. The support person can still view your account to help you, but can no longer change forms or import applications.
Every change a support person makes is recorded in your audit log under their name, including forms they created, versions they published, the active form they chose, and each import they ran.