One of the most requested features from some of the NGOs using Glific—especially those working with large groups like students—was the ability to deactivate profiles. This was particularly important for teams like Alokit, where teachers manage profiles for each of their students. Each student gets a profile, and when they finish their course, that profile is no longer relevant, but until now, there was no way to archive or clean them up. The result? An ever-growing, cluttered list of profiles.

So we rolled up our sleeves and got to work on solving this in a clean, sustainable way.

The Original Plan: Simple and Straightforward

We started with a modest scope:

1. Add an is_active flag to the profile table
   
2. Add backend support to deactivate profiles
   
3. Update select queries to return only active profiles
   
4. Add @contact.active_profile_name variable for use in flows
   
5. Sync the new field to BigQuery (for reporting purposes)
   
6. Add a “Deactivate Profile” option in the Manage profile node

At this stage, the feature looked simple enough: NGOs could mark old profiles as inactive, and those profiles would disappear from flows and reports. Clean and efficient.

First Implementation: Soft Delete with Fallback

We added a Deactivate Profile option in the Manage Profile node. Until then, users could only create or switch profiles. Now they could deactivate one too.

When you chose to deactivate a profile, the system would:

1. Show you the list of existing profiles
   
2. Ask for the profile index
   
3. Deactivate the chosen profile (set is_active = false in the DB)

To avoid leaving the contact stranded, we made sure that once a profile was deactivated, the system automatically switched back to the default profile (more on that below).

This was essentially a soft delete: we didn’t lose any data, but the profile wouldn’t appear in active lists anymore.

At this stage, the goal was to give NGOs a basic way to mark old profiles as inactive and ensure those profiles no longer showed up in contact-related flows or data exports.

The Curveball: What Happens to the Contact?

Halfway through development, a problem popped up:

> What happens if a contact’s current active profile is deactivated?

If we simply removed it, we’d be left with a contact that has no identity, no data, and no clear way to function in a flow, and essentially leave the contact in limbo. Not ideal.

This prompted a deeper rethink. We realized we needed a reliable fallback—a way to restore a contact’s state if their active profile is removed.

The Default Profile: A Fallback with Meaning

The solution was to introduce the concept of a Default Profile.

Here’s how it works:

• When a contact creates their very first profile, we capture their existing contact fields as a default profile.
  
• This default profile represents the base identity of the contact.
  
• If a contact’s current profile is ever deactivated, we revert them to this default profile—updating fields and marking it as the new active profile.
  

This way, the contact never loses their structure or identity, and flows remain predictable.

But Wait, What If…

We had a few more questions to tackle:

• What if someone tries to deactivate the default profile?
  That’s a no-op. We silently ignore the action and move on.
  
• What if someone tries to delete the default profile?
  That’s more serious. Since the default profile is tightly linked to the contact itself, deleting it essentially deletes the contact. To prevent surprises, we now show a confirmation dialog clearly stating what will happen.
  
• How would users know which profile is which?
  To avoid confusion, we added visual cues in the UI:
  
  • “Default” next to the default profile
    
  • “Current” next to the currently active one
    

These labels help users confidently manage profiles without second-guessing themselves.

A Feature That Grew with Us

What started as a small addition turned into a deeper exploration of how Glific thinks about contacts and their identity over time. Along the way, we:

• Balanced data integrity with user flexibility
  
• Kept the NGO experience front and center
  
• Made sure the system stays predictable, even as contacts evolve
  

This feature was a true collaboration—between product thinking and engineering. We found ourselves constantly putting on the “user hat” to make sure the experience made sense.  For one of us, it was the first feature shipped in Glific; for the other, it was a reminder that even the simplest feature can surface complex, meaningful questions.

We’re excited to see how NGOs put this to use—and as always, we’re listening for what comes next.