Skip to main content
Last updated on

LinkedIn Ads connector limitations

Beta

This feature is in Beta. Workspace admins can control access to this feature from the Previews page. See Manage Databricks previews.

Learn about known limitations when using the managed LinkedIn Ads connector in Lakeflow Connect.

General limitations​

  • When you run a scheduled pipeline, alerts don't trigger immediately. Instead, they trigger when the next update runs.
  • When a source table is deleted, the destination table is not automatically deleted. You must delete the destination table manually. This behavior is not consistent with Spark Declarative Pipelines on Lakeflow behavior.
  • During source maintenance periods, Databricks might not be able to access your data.
  • If a source table name conflicts with an existing destination table name, the pipeline update fails.
  • Multi-destination pipeline support is API-only.
  • You can optionally rename a table that you ingest. If you rename a table in your pipeline, it becomes an API-only pipeline, and you can no longer edit the pipeline in the UI.
  • If you select a column after a pipeline has already started, the connector does not automatically backfill data for the new column. To ingest historical data, manually run a full refresh on the table.
  • Databricks can't ingest two or more tables with the same name in the same pipeline, even if they come from different source schemas.
  • The source system assumes that the cursor columns are monotonically increasing.
  • The connector ingests raw data without transformations. Use downstream Spark Declarative Pipelines on Lakeflow pipelines for transformations.

Supported tables​

The connector supports the twelve predefined tables listed in LinkedIn Ads connector reference. You cannot define custom reports.

Incremental ingestion​

  • Only the seven prebuilt report tables support incremental ingestion. The five entity tables are fully refreshed on each pipeline update.
  • Entity tables do not support history tracking (SCD type 2). Only the current state is stored.
  • A report that has already synced resumes from its own cursor, so lowering sync_start_date after the first update does not backfill it. Only newly appearing accounts or campaigns start from the new date. To re-ingest earlier history, run a full refresh on the table.
  • Deleted campaigns and ad accounts keep their entry in the connector's tracked state and simply stop advancing. Rows already ingested into the destination table remain there; the connector does not delete them.

Data retention​

LinkedIn retains performance data for 10 years and professional-demographic data for 2 years. A sync_start_date earlier than the horizon that applies to the report is rejected, because data before it cannot be retrieved from the API.

Report configuration​

  • Each prebuilt report has a fixed configuration. Its pivot, time granularity, and metric set are set per report and cannot be overridden.
  • The five demographic reports are aggregated per campaign rather than per creative, because LinkedIn's demographic responses do not carry the creative.
  • Monthly reports cannot be narrowed below a calendar month. LinkedIn returns no rows for a sub-month range at monthly granularity, so a sync_start_date that falls mid-month is aligned to the first of that month, and the row returned for that month is the full-month aggregate.

Time zone​

Report date boundaries are evaluated in UTC rather than in the ad account's time zone, and you cannot override this.

Authentication​

  • The connector reads only the ad accounts that the authorizing user has a role on. To ingest an ad account, ensure the user who authorizes the connection has a role on it.
  • LinkedIn issues access tokens with a 60-day lifespan. LinkedIn also invalidates a user's existing tokens for an app when a new authorization requests a different set of scopes.
On this page