---
title: Frequently Asked Questions (FAQ)
slug: frequently-asked-questions-faq
createdAt: 2025-10-29T21:29:43.713Z
---

# How many connectors can run at once?

There’s no hard limit — connectors are lightweight and can run concurrently, limited only by available server and SQL resources. Stagger large imports to avoid database contention.

# What happens if the schema changes?

Activate validates schema on every run. If a mismatch is detected, the connector will stop with an error. Always append new columns and never modify or reorder existing ones.

# Can I connect to cloud APIs like Workday or ServiceNow?

Yes — use the **Script Provider** to call REST or SOAP APIs and parse responses. You can also use stored procedures or PowerShell integrations to stage data first.

# How do I stop mass deletions from a bad import?

Set protective limits in your workflow:

:::BlockQuote
\<processImport>
&#x20; \<maxDelete>100\</maxDelete>
&#x20; \<maxChanges>500\</maxChanges>
\</processImport>
:::

If exceeded, the connector aborts and logs an error.

# How can I see what changed in an import?

Query the connector’s **history table** or view change logs in the Activate UI. Each row includes timestamps, action types, and key values.

# Can a single connector update multiple object types?

Yes, but it’s discouraged. Use separate connectors per data domain (Users, Roles, Tickets) to simplify troubleshooting and scaling.

# Why are some updates not applying?

Check:

1. The key field aligns with your schema definition.&#x20;
2. processImport didn’t exceed limits.&#x20;
3. Change handler events exist for the detected actions.&#x20;
4. The target objects (e.g., roles, users) actually exist or are creatable.&#x20;

#

# Can connectors trigger each other?

Yes, through the run workflow step — one connector can launch another when processing completes. Use sparingly to avoid circular dependencies.

# Is there a way to view connector performance?

Yes — monitor run duration, row counts, and error rates in the **Connector Dashboard** or SQL logs. Tracking runtime trends helps identify performance regressions early.
