# 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

* [Designer: Feature Overview](https://welkin-health-1.gitbook.io/welkin-health-docs/designer) – Designer interface overview
* [Configuring Security Policies](/designer/security/configuring-security-policies.md) – Publishing security changes
* [Export Designer Configuration](/designer/version-and-configuration/export-designer-configuration.md) – Detailed export guide
* [Custom Data Types (CDT): Designer](/designer/custom-data-types/custom-data-types-cdt-designer.md) – Changes to CDT structure
* [How to Create an Assessment or Form Template](/designer/documents-and-assessments/how-to-create-an-assessment-or-form-template.md) – Creating new forms tracked in changes


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.welkinhealth.com/designer/version-and-configuration/change-summary-and-version-history.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.