Committing Changes
When you’ve finished editing a module script, commit your changes to push them back to LogicMonitor.
What Is Committing?
Section titled “What Is Committing?”Committing saves your changes from LMDA Composer to the LogicModule in LogicMonitor:
- Script content is updated
- Staged metadata changes are applied
- The module is updated in your portal
- A new version is created
When Can You Commit?
Section titled “When Can You Commit?”The Commit button is available when:
| Requirement | Description |
|---|---|
| Module-bound tab | Tab is loaded from a LogicModule (not a local file) |
| Unsaved changes | You have script or metadata modifications |
| Correct portal | You’re connected to the module’s portal |
| Write permissions | You have permission to modify the module |
Commit Button States
Section titled “Commit Button States”| State | Meaning |
|---|---|
| Commit | Ready to commit—click to proceed |
| Commit | Disabled—no changes or not a module tab |
| Committing... | Commit in progress |
The Commit Flow
Section titled “The Commit Flow”-
Make Your Changes
Section titled “Make Your Changes”Edit the script and/or module details as needed.
-
Test Your Script
Section titled “Test Your Script”Run the script to verify functionality. Check parsed output and validate against mode rules.
-
Review Changes
Section titled “Review Changes”Click Commit to open the confirmation dialog.
-
Enter Commit Reason (Optional)
Section titled “Enter Commit Reason (Optional)”Describe what you changed and why. This is recorded with the version.
-
Confirm
Section titled “Confirm”Click Commit to push changes to LogicMonitor.
-
Verify Success
Section titled “Verify Success”Tab dirty indicator clears. New version created in portal.
Commit Confirmation Dialog
Section titled “Commit Confirmation Dialog”Changes Summary
Section titled “Changes Summary”The dialog shows what will be committed:
| Section | What’s Shown |
|---|---|
| Script Changes | Before/after diff preview with syntax highlighting |
| Metadata Changes | List of modified fields with old and new values |
| Directory Scripts | Additional scripts from module directory (if applicable) |
Commit Reason
Section titled “Commit Reason”Enter a descriptive commit reason explaining your changes (optional but recommended):
- “Fixed SNMP timeout handling for slow devices”
- “Added CPU temperature datapoint (JIRA-1234)”
- “Updated AppliesTo to include Linux 8.x servers”
- “Increased collection interval from 1min to 5min”
- “Updated script” — too vague
- “Changes” — meaningless
- “Fixed bug” — which bug?
- “Test” — not descriptive
Commit Options
Section titled “Commit Options”| Option | Description |
|---|---|
| Script Only | If you only changed the script, only script content is updated. Metadata remains unchanged. |
| Script + Metadata | Both are committed together in a single atomic update. One version created. |
| Metadata Only | From Module Details editor—stage metadata changes and commit without script changes. |
Directory Scripts
Section titled “Directory Scripts”If you’re working with a module directory (local folder linked to a module), you can commit multiple scripts at once:
How It Works
Section titled “How It Works”When a module has a linked directory with multiple script files (e.g., collection script and AD script), the commit dialog shows all scripts with changes.
| Column | Description |
|---|---|
| Checkbox | Select which scripts to include in the commit |
| Script Name | The script file (e.g., collection.groovy, ad.groovy) |
| Status | Whether the script has changes |
Selecting Scripts
Section titled “Selecting Scripts”-
Open the commit dialog
-
Review the list of directory scripts
-
Check/uncheck scripts to include or exclude
-
Only selected scripts with changes will be committed
Handling Errors
Section titled “Handling Errors”If validation fails:
- Error message displayed
- Commit blocked
- Fix issues and retry
Common causes:
- Script exceeds 64,000 character limit
- Required metadata fields empty
- Invalid AppliesTo syntax
If you lack permissions:
- 403 error displayed
- Contact your LM administrator
- Check your role assignments in LogicMonitor
If the module was modified by others:
- Conflict warning shown
- Reload the module to see current state
- Merge your changes manually if needed
If the connection fails:
- Retry option available
- Check your LM session (may have expired)
- Verify network connectivity
After Committing
Section titled “After Committing”Verify in LogicMonitor
Section titled “Verify in LogicMonitor”-
Open LogicMonitor in your browser
-
Navigate to the module in Settings → LogicModules
-
Verify your changes appear in the script
-
Check version history shows your commit
Active Discovery Impact
Section titled “Active Discovery Impact”If you changed AD scripts:
- Discovery runs on next scheduled interval
- Or trigger manual discovery from device
- Verify expected instances are found
Collection Impact
Section titled “Collection Impact”Script changes take effect immediately:
- Next collection uses new script
- Monitor for errors in Alerts
- Check data continuity in graphs
Best Practices
Section titled “Best Practices”- Always Test First — Run the script multiple times with different devices. Verify output parsing and check edge cases.
- Use Descriptive Reasons — Your commit reason helps future you, team members, and auditors understand changes.
- Commit Small Changes — Prefer frequent small commits over large batches. Easier to identify issues and revert if needed.
- Coordinate with Team — Communicate planned changes for shared modules. Avoid simultaneous edits.
- Back Up Before Major Changes — Export scripts to local files before significant modifications.
Commit vs. Save
Section titled “Commit vs. Save”| Action | What It Does | Where Saved |
|---|---|---|
| Save | Saves to local file | Your computer’s disk |
| Commit | Pushes to LogicMonitor | LM portal (creates new version) |
You can save locally as backup before committing.
Emergency Rollback
Section titled “Emergency Rollback”If a commit causes problems, you’ll need to:
- Restore from backup: If you exported the script before making changes
- Rewrite manually: Undo the problematic changes by hand
- Check Lineage (for core modules): If you’re working with a LogicMonitor Exchange module, you can view the original Exchange version via Lineage and use it as a reference