It's currently possible to make a report parameter that selects a Survey, but the same is not possible for Custom Tables

I was testing my manual patch to the CA module chronicity calculations that I have been using since we found the issue in 60.3 in 61.1.3 by comparing the client profile version of chronicity to the one reported by the CA module.

Running the following query, I was finding some cases where the client had become chronic (according to the CA calculations) but their profile was still saying “No” for chronically homeless, and the opposite situation as well where the client was no longer considered chro…

With a mechanism to record eligibility requirements, e.g. for a housing unit, service provider, or program, it would be possible to filter a priority list to just show eligible clients.

Note that this idea is being developed as part of the HIFIS Improvement Project. More details will be added as this is further developed. Get involved and have your say!

If you have a custom Consent Value that rolls up to Coordinated Access or Explicit + Coordinated Access, clients with those statuses are missing from the Coordinated Access module.

Allow users to record a client's housing needs and preferences natively without a custom table.

Note that this idea is being developed as part of the HIFIS Improvement Project. More details will be added as this is further developed. Get involved and have your say!

Another small enhancement to the Housing Maintenance module would be to add a filter on the Housing Maintenance List to show the status of maintenance: Completed (i.e. Actual To Date is not null), Pending (i.e. Actual From Date is in the past and Actual To Date is null), or Upcoming (i.e. Actual From Date is null) maintenance. 

It may also be helpful to change the columns presented on the Housing Maintenance List to display this status also.

Several HIFIS users want a way to be able to track necessary repairs to housing units. It is logical that these repairs be able to be tracked in the Housing Maintenance module, but there is one problem preventing this use: the fact that both the Scheduled Start Date and Actual Start Date fields are mandatory. This prevents a user from adding a Maintenance Log to indicate that maintenance is necessary, but hasn’t been scheduled yet. The simplest solution is to make these fields optional.

"Status" implies occupancy status. "Condition" better describes what the field contains.

This would allow users to add more information about the Waiting List itself, such as eligibility criteria.

Subsidies are connected to Housing History records, not Housing Placements or Housing Loss Prevention. However, in order to add a Subsidy, you must first add a Housing Placement or Housing Loss Prevention.

Can we please have the ability to add a subsidy directly from the Housing History?

And then filter the list of Waiting Lists to show Active by default.

Ticket #16873 (Note: Impacts Crystal Reports)

• August 8, 2026 - HIFIS National replied that changes are to be implemented in an upcoming release

A list of known errors in HIFIS_ClientHistoryChanges for Last Known City

• No record is created for the first city record

• When you add a backdated Housing History record, for example, one that says the client moved in last week, the date of change is today

• If you edit a current/most recent Housing History record and change the city, the previous city's value remains in the history of changes and a new record is created (this may be intentional)

• If you edit an older Housing History record (not the most…

Short version: disabling a User Account does not remove them from drop-down staff selectors, like Caseworker.

Longer version: In the background, each User account also has a corresponding People record, and these are linked to each other. To control whether someone can login or not, you'd activate/deactivate their User account. However, activating/deactivating the User account doesn't impact the activity status of the People account. It is the People information that determines whether that user …

Now that HIFIS has been in use for 10+ years in some communities, many communities have generated a high volume of data, and the oldest data shouldn't be kept according to privacy best practices. HIFIS should have a built-in mechanism to automatically remove or archive data older than 7 years, to prevent the system from getting to bloated and also to adhere to data retention rules.

1. Create a Custom Table attached to a Case file

2. Create a Case

3. Create a Custom Record for that Case

4. Delete the Case

5. The Custom Record will remain in the database and not get removed

In my community, clients are considered 'paper ready' when their profile includes three things: ID, a SPDAT conducted in the last 12 months, and proof of income. When a client has these things, it means they are eligible to be matched to a Housing Program.

In addition to uploading information in three different modules (Identification, Documents and SPDAT), users must fill out a custom table indicating the client is paper ready. Information from the checklist is used in our BNL to streamline the …

Currently, HIFIS users are required to add a Housing History record for each member of the family. This is time consuming for families with multiple individuals. Our HIFIS user have asked for an improvement idea where users would be able to create a Housing History record for one member of the family and then select other members of the family for that information to be replicated. This would significantly reduce the administration task of updating multiple Housing History records separately. 

A source of income is updated to have an end date in the future. If someone adds a new source of income with a start date also in the future, then the total income amount and accompanying chart updates incorrectly. The total income should only be the current amount that doesn't end for a few more months. However, in 60.5 the Total income shows up as both incomes added together, which is incorrect.  See image for an example.  

I can't believe I don't already have something on this ideas board about this! Here's the idea, in more detail:

In a perfect world, we have 100% complete housing-related data about all clients at all times. But we do not live in a perfect world, and there are frequently gaps in each client's history. For example: a client books out of shelter on Tuesday and back into shelter on Thursday, and staff may not remember to/get a chance to/prioritize asking them where they were for the one missing night…

When a client reaches the Minimum Age of Consent, the "Inherited Consent" should expire automatically.

In the HIFIS_ServiceTypes table, the list of values is as follows: (NameE, ActiveYN)

Stay Y
Emergency N
Transition N
Non-Shelter N
Goods and Services Y
Storage N
Reservations Y
Turnaways N
Housing Y
Food Bank Y
Other N
Case Management Y
SPDAT Y
Housing Subsidy Y
VAT Y
Group Activities Y
Housing Loss Prevention Y
Diversion Y

However, of these, several do not do anything: Emergency, Transition, Non-Shelter, and Other. All four of these are currently set to "ActiveYN" = "N"

Additionally, Storage and Turnaways are also…

In some cases, staff have added a service to Client A when it should have been attached to Client B. It would be useful to be able to detatch a service from one client and re-assign it to a different client.

To some extent, merging the client files can address this, in the case of duplicates, but that doesn't solve all problems - what if we really do have two different clients with a similar name and I accidentally open a case file for the wrong John Smith? The current required workaround is to d…

Let's re-imagine Case Management. Right now, you can add Sessions, Comments, and Documents to it.

However, a point of ongoing debate is when to add a Service as in Goods & Services, and when to add a Case Session. They have similar but different fields and are stored differently in the database. Here's a radical idea: get rid of Sessions entirely and modify the Services so that they can be added either as part of a Case file or as an independent, non-associated Service. It would also be great i…

Each time I create a new Diversion record and select a Caseworker, a Failed to Save error message appears in the top right corner of the screen. In some cases, the Caseworker name is still saved. In other cases, the Caseworker selection does not save.

My current assessment is that the Diversion module may not be handling custom Reason for Service values correctly.

Test 1 – Used a Standard Lookup Value
I created a Diversion record using a standard Reason for Service lookup option. When I added a Good or Service through the Diversion record, the same Reason for Service value auto-populated into the Good/Service record.
Result: Worked as expected.

Test 2 – Used a Custom Lookup Value
I created a Diversion record using one of our custom Reason for Serv…

My solution has three parts:

1. Implement an "unknown gap threshold."

2. Introduce a new table (or alternatively, you could repurpose the "Risk of Homelessness" table) that includes a bunch of date-stamped housing values. This would contain values like "on Thursday, Client Y was Homeless" or "on Saturday, Client Z was Housed." This is a date-stamp value as opposed to a date-range, so it does not have a duration. You're not asking for a start or end date. You're just saying they were or were not homeless…

In Housing Placements, the Search Ended Date field shows the latest of:

• Final Follow Up

• Final Attempt

• Move-In Date

But Follow Ups happen, by definition, after the search has ended, so adding a Follow Up should not affect the Search Ended Date

Communities often want to know what service provider created a record. By default, most if not all HIFIS records have the following columns:

• Created By (User ID)

• Created Date (Datetime)

• Last Updated By (User ID)

• Last Updated Date (Datetime)

But they're missing a record of what Service Provider the user was logged into at the time. It would be helpful to include this information for all records.

Veteran Summary is missing Created By, Created Date, Last Updated By, Last Updated Date