Application Data: Service Files

The Service File acts as the primary record for applicants and residents/owners. All application data is saved to the Service File and its related records (Contact, Household Members, Assets, Debts, Income Sources, Required Documents, etc.)

Salesforce Contact

The Contact record is the primary person record in Salesforce. All other activities are linked to the Contact record – applications (Service Files), donations, volunteer history, etc. Contact records are created for applicants and co-applicants. Both are link Public House is the key to SalesForce Contact is key to linking the Service File to the Application and applicant log-on. The Contact is linked throughout sections of the Service File to associate data to the right household member.

When a co-applicant is added to the application, a new SalesForce contact is created. Once the co-applicant email is verified, they are able to log into their application using their credentials.

NOTE: HomeKeeper only allows one co-applicant per application.

Applicant/Resident In-put

As applicant data is entered into the application, it is then pushed into the Service File into specific sections that correspond to the application.

As information is reviewed by staff and updated within the Application, it is subsequently updated in the Service File until Application Status= Complete.

Service File Sections

All Service File sections correspond with application sections. While there may be some variation based on customizations, these are the primary Service File sections:

  • Application Details: Primary fields, including the Salesforce Contact; Application & Service File Statuses, the staff link to the Application, Program Type, and Property link
  • Application Process: Displays when the key application dates occur, from application invitation to approval date.
  • Application History: An audit trail of what happened, when, and by whom. On extensive Service Files, the history can exceed the length Salesforce allows us to save. In this case, the first half of the history is deleted.
  • Qualification Information: Income Limits by household size, household size, total household income, assets, debt, and maximum allowable rent, if applicable. ‘Certified’ values indicate the values are finalized for the application cycle.
  • Income Sources, Assets, Debts: Roll-ups of each of these types as entered in the application.
  • Imputed Income: The details behind an imputed income calculation, if applicable
  • Income Calculation: The AMI schedule, the maximum allowable AMI percentage, minimum income values and (rent) calculation type, if applicable
  • Required Documents: Displays all the required documents requested as part of the application process; opening these shows more details on the document uploads, including the overall status and the specific documents uploaded as part of each Required Document Template.
  • Household Members: Displays all household members and household member details from the application. Links to the Salesforce contact for the primary applicant and co-applicant.
  • Activity History: Displays automated emails sent to the applicant/resident

In addition, links to the Campaign Members, Intakes, and Monitoring Events are accessed through the Service File. The page layouts can be customized as can additional fields- visit Trailblazer for more information on this!


While the goal is to have a smooth, application process mistakes, corrections need to be made and automations may require manual overrides. If this is the case, it is sometimes best to make edits directly in the Service File. Some examples include:

  • Required Documents: A Required Document was Approved, but you realize later in the process that you are missing information. Open the specific Required Document Template on the Service File and manually edit the status from Approved to Document Review.
  • Income Limits: If you are processing a transfer for a rental applicant, the automated income limit may need to be manually overridden from a move-in limit to a renewal limit.

Tracking Field History

We recommend tracking field history on a handful of Service File and Contact fields, which displays the history on the Service File when these fields are changed. This helps to resolve fringe cases that arise from strange applicant or staff behavior. Below are links to instructions for tracking field history on Service Files and Contacts. 

Tracking Field History on Custom Objects

Service Files

  • Service file name
  • Program
  • Applicant
  • Co-Applicant
  • Status
  • Application Status
  • Close Date
  • Property
  • Application Invitation
  • Application Due

Tracking Field History on Standard Objects

Contact Fields

  • First Name
  • Last Name
  • Email
  • Phone