Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Change Summary and Version History

Overview

The Change Summary is the first page you see when logging into Designer. It provides a comprehensive view of all modifications made to your Welkin configuration during your current work session and historical versions of your configuration. Understanding how to work with drafts and versions is essential for managing configuration changes safely and collaboratively.

Key Concepts

  • Draft – A working copy of your configuration that you can edit without affecting production

  • Version – A published snapshot of your configuration that is live in production

  • Change Summary – A log of all modifications made within the current draft

  • Version History – Complete history of all published versions over time

  • Publish – The action that converts a draft into a live version

Working with Drafts

Creating a Draft

Drafts allow you to work safely without impacting production:

Option 1: Create from Current Version (Recommended for Most Changes)

  1. On the Designer homepage, click Create Draft

  2. Select Create from current version

  3. Click Submit

When to use:

  • Making updates to existing configuration

  • Adding new features to current setup

  • Modifying existing components

  • Makes changes on top of current live version

Option 2: Create from JSON File (For Importing Previous Configurations)

  1. On the Designer homepage, click Create Draft

  2. Select Create from file

  3. Click Choose File and select a JSON configuration file from your computer

  4. Click Submit

When to use:

  • Importing a previously exported configuration

  • Restoring an older version you have saved

  • Loading a configuration template

  • Testing a configuration before it's live

Viewing the Change Summary

Once you have an active draft, the Change Summary displays:

  1. Draft Name – Identifier for this draft work session

  2. Changes Made – Chronological list of all modifications:

    • What was added (e.g., "Created new custom data type: cdt-vitals")

    • What was modified (e.g., "Updated field 'medication_name' in cdt-medications")

    • What was deleted (e.g., "Deleted form: Old Survey Form v1")

    • When each change was made (timestamp)

    • Who made the change (if multi-user environment)

  3. Status – Indicates if draft is ready to publish or has issues

Understanding Changes Displayed

Changes by Component Type

Custom Data Types (CDTs)

  • New CDT created

  • Fields added to existing CDT

  • Field properties modified (type, required status, etc.)

  • CDT deleted or archived

Visual Components (Forms, Charts, PDFs)

  • New form/assessment created

  • Form questions modified

  • Conditional logic added/updated

  • PDF templates added

  • Form deleted

Programs and Phases

  • New program created

  • Phases added/modified

  • Program associations updated

  • Program deleted

Automations

  • New automation rule created

  • Trigger or condition modified

  • Action added/changed

  • Automation deleted

Security Policies

  • New policy created

  • Role permissions modified

  • Field-level security updated

  • Policy deleted

Message Templates

  • New template created

  • Template content modified

  • Variables or filtering updated

  • Template deleted

Reviewing Changes Before Publishing

Best practice workflow:

  1. Work in Draft – Make all your configuration changes

  2. Review Change Summary – Read through all changes made

  3. Verify Each Change – Confirm each change is as intended

  4. Look for Unintended Changes – Check if you accidentally modified something

  5. Test in Draft (if possible) – Verify configuration works as expected

  6. Publish – When satisfied with all changes

Publishing and Creating Versions

Publishing Your Draft

When you're ready to make changes live in production:

  1. In the Change Summary, review all changes one final time

  2. Click Publish button

  3. System may ask for confirmation:

    • "Are you sure you want to publish these changes?"

    • Review the list of changes once more

  4. Click Confirm Publish or Yes

  5. Draft is now published as the new live version

  6. All users in Care see the new configuration immediately

What Happens When You Publish

  • All changes in the draft become live

  • Previous version is archived in version history

  • A new version number is created

  • Timestamp is recorded

  • User/admin making change is logged

  • All care team members see the new configuration

Version History

Accessing Version History

  1. In Designer, look for Version History or Versions section (may be accessed from homepage or settings)

  2. View complete list of all published versions:

    • Version numbers (v1.0, v1.1, v2.0, etc.)

    • Publication date/time

    • Changes in each version

    • User who published

Reading Version Information

Each version shows:

  • Version Number – Sequential identifier

  • Published Date – When it went live

  • Published By – User who published (if tracked)

  • Summary of Changes – Key modifications in that version

  • Configuration Details – Full configuration exported as JSON

Comparing Versions

Some Designer interfaces allow version comparison:

  1. Select two versions to compare

  2. System shows differences between them:

    • What was added

    • What was removed

    • What was modified

    • Fields that changed values

Reverting to a Previous Version (If Supported)

Some organizations can revert to a previous version:

  1. In Version History, select the version you want to restore

  2. Click Revert or Restore button

  3. System creates a new draft based on that older version

  4. Review changes and publish when ready

Note: Reverting creates a new version; it doesn't delete intervening versions. All history is preserved.

Export and Backup Workflow

Exporting Configuration

To create a backup of your current configuration:

  1. In Designer, look for Export or Download Configuration

  2. Click to export current live version as JSON file

  3. Save the JSON file to your computer with a descriptive name:

    • Example: welkin-config-v2.0-2026-03-21.json

    • Include version number and date

When to Export

  • Before making major changes to configuration

  • Before publishing significant updates

  • Regular scheduled backups (weekly/monthly)

  • Before switching configurations

Using Exported Configurations

Exported configurations can be:

  • Backed up – Stored safely for disaster recovery

  • Shared – Sent to other team members for review

  • Imported – Loaded into Draft via "Create from file" option

  • Documented – Stored with version control alongside other company records

Best Practices

  1. Frequent Drafts – Create new drafts for distinct pieces of work rather than one massive draft

  2. Descriptive Naming – If able to name drafts, use names indicating what you're working on

    • "Add Depression Screening Assessment"

    • "Update Security Policies for New Roles"

    • "Fix Medication Automation Bug"

  3. Review Before Publishing – Always review Change Summary before publishing

  4. Test First – If possible, test changes in a staging environment

  5. Regular Backups – Export and backup configuration regularly

  6. Change Log – Keep external documentation of significant changes and why they were made

  7. Incremental Changes – Publish smaller changes frequently rather than large batches infrequently

  8. Team Awareness – Notify team before publishing changes that affect their workflows

  9. Version Documentation – Document major version changes:

    • What changed

    • Why it changed

    • Who requested the change

    • When it was published

    • Impact on care team

  10. Rollback Plan – Know how to quickly revert if published changes cause problems

Common Scenarios

Scenario 1: Adding a New Assessment

  1. Create Draft from current version

  2. Create new Form/Assessment in Visual Components

  3. Configure questions, fields, and conditional logic

  4. Review Change Summary (should show 1 new form + multiple field additions)

  5. Publish when ready

  6. Assessment appears in Care app

Scenario 2: Updating an Existing Field

  1. Create Draft from current version

  2. Navigate to the CDT and field that needs updating

  3. Modify field properties (type, options, required status, etc.)

  4. Review Change Summary (should show field update)

  5. Publish

  6. Field behavior changes in all assessments using it

Scenario 3: Creating Multiple Interconnected Changes

  1. Create Draft from current version

  2. Create new CDTs and fields for a program

  3. Create new assessments using those fields

  4. Create automations that reference the assessments

  5. Update security policies to control access

  6. Review Change Summary (should show multiple additions across categories)

  7. Publish as a coordinated release

Scenario 4: Testing and Publishing Safely

  1. Create Draft from current version

  2. Make proposed changes

  3. Review Change Summary and export as JSON

  4. If possible, test with care team in staging environment

  5. Collect feedback

  6. Make adjustments if needed

  7. Publish when team agrees

Related Topics

PreviousDesigner OverviewNextMulti-User Collaboration in Designer

Last updated

Was this helpful?