Cloud / Amazon AppFlow Interview questions

Amazon AppFlow is a fully managed integration service that moves data between SaaS applications and AWS services without you writing or hosting integration code. You pick a source, a destination, a trigger and a field mapping, and AppFlow handles authentication, pagination, API throttling and delivery.

A typical use is pulling Salesforce opportunities into Amazon S3 every hour, or pushing records from S3 back into Salesforce.

There are no servers to manage and no upfront fees. You pay per flow run plus the volume of data processed.

A flow is built from a handful of pieces, and interviewers usually expect you to name them in the order you configure them.

1. Source - the connector and object to read from, such as the Salesforce Account object.
2. Connection (connector profile) - the stored credentials used to reach the source or destination.
3. Destination - where data lands, such as an S3 bucket or Snowflake table.
4. Trigger - on demand, on a schedule or on an event.
5. Field mapping and tasks - which fields move and how they are transformed.
6. Filters - optional conditions that limit which records are transferred.

AppFlow supports three trigger types.

• Run on demand - you start the flow manually from the console, CLI or API, for ad hoc transfers.
• Run on event - the flow starts when the source app publishes a supported event, such as a Salesforce change event.
• Run on schedule - the flow repeats at a fixed interval, as often as once per minute for many sources.

Scheduled flows can do a full transfer or an incremental transfer, and that choice is separate from the trigger type.

A connector is the component that knows how to talk to one specific application or AWS service. It handles that app's authentication method, its object model, its API limits and how to read or write records.

Salesforce, ServiceNow, Slack, Zendesk, Amazon S3 and Snowflake are all separate connectors. Each connector may act as a source, a destination or both, depending on what the vendor API allows.

If a SaaS app you need is not on the list, you can build a custom connector with the Custom Connector SDK.

A connection (called a connector profile in the API) stores the details AppFlow needs to sign in to an application, such as OAuth tokens, usernames, passwords or API keys, plus instance URLs.

You create it once and reuse it across many flows. For example, one Salesforce production connection can feed five different flows. Credentials are stored encrypted, using an AWS managed key or your own KMS key.

Rotating a credential means updating the connection, not every flow that uses it.

AppFlow ships with dozens of connectors. Sources include Salesforce, ServiceNow, Slack, Zendesk, Marketo, Google Analytics, Datadog, Dynatrace, SAP OData and Amazon S3.

Destinations include Amazon S3, Amazon Redshift, Snowflake, Salesforce, Amazon EventBridge, Upsolver and Zendesk, among others.

Support is per connector, not universal. Some apps are source-only, and some destinations accept only certain operations, so always check the connector page before you design around one.

A quick way to answer in an interview is to group them: business apps (Salesforce, Zendesk, ServiceNow), marketing and analytics (Marketo, Google Analytics), observability (Datadog, Dynatrace) and AWS or data platforms (S3, Redshift, Snowflake). Custom connectors extend the list when your app is missing.

Field mapping tells AppFlow which source fields go to which destination fields. Without it, the destination would not know where to put each value.

You can map fields one by one, map all fields directly, or upload a CSV of mappings. Mapping tasks also let you rename fields, and this is where transformations such as concatenation, truncation, masking and validation are added.

Mapping is fixed when you save the flow, so a new source field will not appear at the destination until you update the flow or use the map-all option.

From the console the process follows a wizard, and the CLI and API mirror the same steps.

1. Enter a flow name and optional description, and choose encryption settings.
2. Choose the source, select or create a connection, and pick the object.
3. Choose the destination and its options, such as the S3 bucket, prefix and file format.
4. Choose the trigger: on demand, on event or on schedule.
5. Add field mappings, optional validations and filters.
6. Review and create the flow, then activate it or run it.

In code you would use create_flow in the SDK or an AWS::AppFlow::Flow resource in CloudFormation.

Scheduled flows offer two transfer modes.

If a run fails, an incremental flow picks up from the last successful run so no changes are skipped.

Rule of thumb: start with a full transfer to seed the destination, then switch to incremental for the ongoing loads.

Scheduled and event-triggered flows must be activated before they start running. On the flow details page you choose Activate flow, and AppFlow begins running it on its trigger.

Deactivating stops future runs but keeps the flow definition, mappings and connection. You can reactivate it later. Deleting removes the flow completely, and data already written to the destination stays where it is.

On-demand flows have no active state. You simply start a run whenever you need it.

Deactivate a flow before you change its connection or destination, so a half-edited setup does not run. Because runs are billed, deactivating unused scheduled flows also stops the charges.

When S3 is the destination, AppFlow can write CSV, JSON and Parquet files.

• CSV - easy to open in spreadsheets and simple tools.
• JSON - keeps nested structure and is common for API-style data.
• Parquet - columnar and compressed, the best choice when Athena or Redshift Spectrum will query the data.

The format is set in the destination options, alongside the filename and folder preferences.

If you are unsure, pick Parquet for analytics workloads and JSON when the data is nested or will be consumed by an application. CSV is fine for small extracts that people open in a spreadsheet.

Filters limit which records are transferred, based on conditions you define on source fields. Only records that match are sent to the destination.

For example, you can transfer only Salesforce opportunities where Stage equals Closed Won, or tickets created after a certain date. Filtering at the source reduces the data processed, which lowers cost, and it keeps unwanted or sensitive records out of the destination.

Each source connector supports its own set of filterable fields and operators.

Filters are set per source field with operators such as equals, contains, greater than or between, and several conditions can be combined. Remember that incremental flows still respect these filters on every run.

Masking is a transformation task that hides part of a field's value before it reaches the destination. You choose the field and a mask character, and AppFlow replaces the characters with it.

A phone number such as 9876543210 could arrive as ******3210 depending on your settings. It is useful for personal data like phone numbers or account numbers that analysts do not need in full.

Masking happens during the flow, so the raw value is never written to the destination.

AppFlow pricing has two parts.

1. Flow runs - a charge per successful run, currently $0.001 per run. A run that checks for new data and finds none still counts.
2. Data processing - a per-GB charge for the data moved through the service, aggregated across all flows in the account each month. The rate depends on region and on whether the destination is on AWS or uses PrivateLink.

There are no upfront fees. AWS data transfer fees do not apply on top of the data processing charge, though other services you combine with it, like S3 and KMS, bill separately. Check the current pricing page before quoting rates.

An event-triggered flow starts when the source application publishes a supported event, instead of on a timer. AppFlow receives the event and runs a transfer for the changed data.

A common case is Salesforce change data capture: when an account record is updated, the flow starts and sends the change to S3 or another target. This gives near real-time sync without polling.

Only some connectors expose events, so this trigger is not available for every source.

Because each event starts a run, keep an eye on the flow run count for busy objects. For high-volume sources a short schedule with incremental transfer can be cheaper than reacting to every event.

When S3 is the destination, AppFlow can register the transferred data in the AWS Glue Data Catalog. You give it a database name and an optional table prefix, and AppFlow creates or updates a table for each flow.

Once the table exists, you can query the data with Athena, Redshift Spectrum or other catalog-aware tools without running a crawler yourself. Parquet output works best here.

The flow needs an IAM role with permission to create and update tables in the catalog.

Custom connectors let you connect AppFlow to an application that has no built-in connector, such as an internal API or a niche SaaS product. You build them with the Custom Connector SDK in Java or Python.

The connector runs as an AWS Lambda function that AppFlow calls to fetch metadata and read or write records. Once registered in your account, it shows up like any other connector when you build a flow.

You can also use connectors published by partners through AWS Marketplace.

Start with the run history on the flow details page. It shows each run's status, start time, records processed and the error message for failures.

For automation, AppFlow publishes start and end flow run report events to Amazon EventBridge, and you can route them to Lambda, SNS or Step Functions. Metrics are also emitted to CloudWatch, so you can alarm on failed runs, and CloudTrail records API calls for audit.

A practical setup is one EventBridge rule that filters end reports for failed status and publishes to an SNS topic. That gives the team an email or chat alert without polling the console.

Data moving between the source, AppFlow and the destination is protected with TLS. At rest, AppFlow encrypts stored items, including connection credentials, with AWS KMS.

By default it uses an AWS managed key. If policy requires it, you can supply a customer managed KMS key when you create the flow or connection, and you then control the key policy and rotation.

Access is governed by IAM, and API activity is logged in CloudTrail. For traffic that must avoid the public internet, add PrivateLink on supported connectors.

In an interview, also mention least-privilege IAM: give the flow creator only AppFlow actions, and scope the S3 bucket policy to the specific bucket and prefix instead of all buckets.

PrivateLink keeps flow traffic on the AWS network instead of the public internet. That reduces exposure to internet-based attacks and satisfies rules that forbid public routes for sensitive data.

It is available for supported connectors such as Salesforce and Snowflake. You enable private connectivity when you create the connection, and the source application must also be set up for it, for example Private Connect on the Salesforce side.

Expect a different data-processing rate for private flows, so compare cost before enabling it everywhere.

Typical reasons are compliance rules for financial or health data, and internal security standards that ban public endpoints. If neither applies, standard TLS over the internet is usually adequate.

In a scheduled flow with incremental transfer, you choose a timestamp field from the source object, such as LastModifiedDate. On each run AppFlow asks only for records where that field is later than the point reached by the last successful run.

The very first run transfers the data that matches your filters. After a successful run AppFlow records where it stopped, so a failed run does not move the bookmark and the next run retries the same window.

flowchart LR
  A["Scheduled run starts"] --> B["Read last successful run time"]
  B --> C["Query source where timestamp > bookmark"]
  C --> D["Write records to destination"]
  D --> E{Run succeeded?}
  E -- Yes --> F["Move bookmark forward"]
  E -- No --> G["Keep old bookmark and retry next run"]

Pick a timestamp that is updated on every change. If the field only records creation time, edits to old records are missed, which is the most common mistake with incremental flows.

You choose a Salesforce change event or platform event as the source, and set the trigger to run on event. AppFlow then listens for those events.

When Salesforce publishes one, for example an update to an Account, AppFlow starts a run and transfers the changed record to the destination. Change data capture must be enabled for the object in Salesforce for change events to be published.

Each event-driven run counts as a flow run for billing, so a busy object can generate many runs in a day.

Because the transfer is driven by events, you avoid polling Salesforce every minute, which also saves Salesforce API calls. Test with a sandbox org first to confirm which events fire for your objects.

Both run automatically, but they start differently and suit different needs.

Choose events for near real-time sync, and schedules for predictable batch loads.

A useful interview follow-up: a schedule gives predictable cost and load, while events give freshness but a run count that follows source activity.

AppFlow focuses on getting data out of, or into, SaaS apps with no code. Glue is a serverless ETL and catalog service built for heavy transformation of data that already sits in AWS or databases.

They are often used together: AppFlow lands raw data in S3, then Glue transforms it.

They solve different problems. AppFlow integrates SaaS applications through their APIs. AWS Database Migration Service replicates databases, including ongoing change capture from engines like MySQL, Oracle and PostgreSQL.

If your data lives in an Aurora or Oracle database, use DMS. If it lives in Salesforce or ServiceNow, use AppFlow.

They can complement each other in one architecture. DMS can replicate the operational database into the lake while AppFlow brings in CRM and support data, and both land in S3 for shared analytics.

Choose AppFlow when a supported connector already covers your source and destination and the transformation needs are light. You avoid writing code for OAuth refresh, pagination, throttling retries and schema discovery.

Choose Lambda when there is no connector, when you need complex business logic per record, or when you must call several APIs in sequence during the transfer.

A custom integration also means you own scaling, monitoring and credential rotation, which is the hidden cost that often tips the decision toward AppFlow.

Ask three questions: is there a connector, are the transforms light, and does the team want to own the code? Yes, yes and no points to AppFlow.

AppFlow supports light, row-level transformations that you add to the field mapping.

• Map - link a source field to a destination field.
• Merge (concatenate) - combine fields, such as first and last name.
• Truncate - cut a value to a maximum length.
• Mask - hide characters in sensitive values.
• Validate - check a field and choose to ignore or stop on failure.
• Filter - limit which records move.

It does not do joins across objects or aggregations. For those, land the data and process it with Glue, Athena or Redshift.

Validation lets you choose per rule whether to ignore the offending record or stop the flow. Combine it with the error bucket so rejected rows are kept for review.

AppFlow loads Redshift in two hops. It first writes the data to an intermediate S3 bucket, then issues a COPY into the target table.

You need a Redshift connection with the cluster details and credentials, an IAM role that lets Redshift read the staging bucket, and the target database and table. The table must already exist with columns that fit the mapped fields.

Failed records can be written to an error bucket, depending on your error handling choice.

If the COPY fails, check that the Redshift role can read the staging bucket and that column types line up with the mapped fields. Numeric or date mismatches are the usual cause.

Use S3 as the source and Salesforce as the destination. AppFlow reads CSV files from the bucket and prefix you choose, maps the columns to Salesforce fields, and writes them with an insert, update, upsert or delete operation.

Keep each CSV file under 125 MB. You can drop several files in the location and AppFlow will process them in a single run, up to the Salesforce export limit of about 500 MB per run.

Column names must line up with the field mapping, and a Salesforce ID or external ID is needed for updates and upserts.

Salesforce field-level security also matters. The integration user must have write access to each field you map, or those columns will be rejected.

For Salesforce as the destination you choose one of four write operations.

• Insert - create new records.
• Update - change existing records, matched on ID.
• Upsert - update if the record exists, otherwise insert, matched on an external ID field.
• Delete - remove records identified by ID.

Upsert is the safest choice for repeatable loads because re-running the flow does not create duplicates.

Insert and delete are the riskiest for reruns. Insert duplicates data if you replay a file, and delete cannot be undone from AppFlow, so test on a sandbox first. Update and upsert also require the mapped ID column to be present in every row.

For destinations such as Salesforce, Snowflake and Redshift you set an error handling preference. You either stop the run when a record fails, or ignore the failed record and continue.

Records that fail are written to an S3 error bucket you specify, along with the reason. You can fix the data and re-run, so the bucket doubles as a dead-letter store.

Errors that break the whole run, such as expired credentials, appear in the run history and in EventBridge end-of-run events.

Use stop-on-error for critical loads where partial data is worse than none, and ignore-and-continue for large batches where a few bad rows are acceptable and can be replayed later.

Two sets of permissions are involved. The person or role creating the flow needs AppFlow actions such as appflow:CreateFlow, appflow:StartFlow and connection permissions.

The destination bucket needs a policy that lets the AppFlow service principal appflow.amazonaws.com write to it, including s3:PutObject, s3:AbortMultipartUpload, s3:GetBucketLocation and the multipart listing actions.

If you use a customer managed KMS key, its key policy must also allow AppFlow to use it.

A common mistake is fixing the IAM policy of the user while leaving the bucket policy unchanged. The flow writes as the service, so the bucket policy is what decides whether the write succeeds. Scope it to the exact bucket and prefix.

EventBridge plays two roles. It can be a destination, where AppFlow sends each record from a SaaS source as an event on an event bus, so rules can fan them out to Lambda, SQS or other targets.

It is also where AppFlow publishes flow run reports, with start and end events that you can match with a rule to send alerts or start the next step of a pipeline.

Events sent as a destination are limited to 256 KB. For larger events AppFlow publishes a summary that points to the full data in S3.

Use the destination role for streaming SaaS changes into an event-driven design, and the run report role for operational alerts. They are independent and can be used in the same account.

CloudFormation has AWS::AppFlow::ConnectorProfile and AWS::AppFlow::Flow resources, and Terraform has matching AppFlow resources. Defining flows this way makes them repeatable across accounts and reviewable in pull requests.

A minimal on-demand Salesforce-to-S3 flow looks like this:

Resources:
  AccountToS3:
    Type: AWS::AppFlow::Flow
    Properties:
      FlowName: sf-account-to-s3
      TriggerConfig:
        TriggerType: OnDemand
      SourceFlowConfig:
        ConnectorType: Salesforce
        ConnectorProfileName: sf-prod
        SourceConnectorProperties:
          Salesforce:
            Object: Account
      DestinationFlowConfigList:
        - ConnectorType: S3
          DestinationConnectorProperties:
            S3:
              BucketName: my-lake-bucket
      Tasks:
        - TaskType: Map_all
          SourceFields: []
          ConnectorOperator:
            Salesforce: NO_OP
          TaskProperties:
            - Key: EXCLUDE_SOURCE_FIELDS_LIST
              Value: '[]'

Keep secrets out of templates by creating the connection with values from Secrets Manager or a secure parameter.

Treat the snippet as a starting point. Add a schedule trigger, filters and an S3 output format as needed, and validate the template in a test account before promoting it.

For an S3 destination you can control how output files are laid out.

• Folder structure - partition output by year, month, day or hour so query engines can skip irrelevant folders.
• Aggregation - either write records as they come, or aggregate all records from a run into a single file, with an optional target file size.
• Filename options - add a timestamp so repeated runs do not overwrite each other.

Partitioned Parquet plus the Glue Data Catalog is the usual setup for cheap Athena queries.

Aggregating into one file per run reduces small-file problems for Athena, while hourly folders help when you need fine-grained time filtering. Pick the granularity that matches how people query the data.

AppFlow calls the source through its public API, so it draws from the same quota as your other integrations. On Salesforce, for instance, flow calls count against the org's API limits.

When the limit is hit, calls are throttled or rejected, and the run can fail or slow down. Fix it by lowering the schedule frequency, using incremental transfer, adding filters, or letting the connector use a bulk API where available.

Also note the connector-specific ceilings, such as how often some sources can be scheduled, before you set an aggressive interval.

Monitor API usage in the source app itself, since AppFlow is only one of the consumers. Coordinate schedules so several flows do not start on the same minute.

These defaults matter most when you design at scale. Some can be raised through Service Quotas and some are fixed.

Individual connectors add their own limits, such as Salesforce import size per run, so read the connector notes too.

Request increases through Service Quotas for the adjustable ones, such as flows per account and monthly runs, before a launch rather than after a failure. Fixed limits like the per-run duration need design changes instead.

A run follows the same path regardless of trigger. AppFlow checks the connection, reads from the source in pages, applies mapping tasks, and writes to the destination.

flowchart TD
  A["Trigger fires"] --> B["Validate connection and permissions"]
  B --> C["Read source records in pages"]
  C --> D["Apply filters and mapping tasks"]
  D --> E["Write to destination"]
  E --> F{Any failures?}
  F -- Records failed --> G["Write to error bucket per preference"]
  F -- None --> H["Publish run report to EventBridge"]
  G --> H

For incremental flows the bookmark is moved only after a successful run. The end report includes records processed and the final status.

Notice that errors can occur at several points. A failure before reading, such as a bad connection, stops the run at once. A failure while writing may affect only some records, depending on your error preference.

Each run also produces a report with the number of records processed, which is what monitoring tools consume.

Land raw Salesforce data in S3, register it in the catalog, and query it with Athena.

flowchart LR
  SF[Salesforce] --> AF["AppFlow scheduled flow"]
  AF --> S3["S3 partitioned Parquet"]
  S3 --> GC["Glue Data Catalog table"]
  GC --> AT["Athena or Redshift Spectrum"]

1. Create a Salesforce connection and a flow with incremental transfer on LastModifiedDate.
2. Write Parquet to S3, partitioned by day.
3. Enable the Glue Data Catalog option so a table is kept up to date.
4. Query with Athena, and use an upsert-style view or job to keep the latest version of each record.

Upserts to the lake are not automatic, since S3 files are immutable. Either keep every version and pick the latest with a query, or run a Glue or Athena job that merges changes into a curated table.

Add a second flow for related objects such as Contact or Opportunity so the lake can be joined later.

Cost has two drivers, so tune both.

• Fewer runs - every run is billed, even an empty one, so use the longest interval the business accepts.
• Incremental transfer - avoids re-processing unchanged records.
• Filters and field selection - transfer only the rows and columns you need.
• Retire idle flows - deactivate flows nobody uses.
• Prefer Parquet - smaller files reduce downstream storage and query cost.

Compare event triggers against schedules for spiky data, because a busy source can generate more runs than an hourly schedule would.

Do the math once: an every-minute flow makes about 43,200 runs per month, versus 720 for an hourly flow. At the per-run price that difference is visible, before any data processing charges.

Work from the outside in, using the error in the run history as your first clue.

1. Credentials - expired OAuth tokens or changed passwords in the connection are the most common cause.
2. Source limits - check for API quota errors on the source app.
3. Mapping and data - a renamed or deleted field, or a value that fails validation.
4. Destination permissions - the S3 bucket policy, the KMS key policy or the Redshift role.
5. Error bucket - read the failed records and reasons written there.

Then create an EventBridge rule on the end-of-run report so future failures alert you immediately.

Reproduce with a single on-demand run after each fix, rather than waiting for the next schedule. If the error message is vague, check CloudTrail for the API call that was denied.

You implement three handlers in Java or Python and deploy them as an AWS Lambda function.

• ConfigurationHandler - validates settings and credentials.
• MetadataHandler - lists the objects and fields the connector exposes.
• RecordHandler - reads records for queries and writes records for a destination.

After deploying the Lambda, you register the connector in your account so it appears in the console, then create connections and flows with it. Test with a small object first, and handle pagination and rate limits inside the handler because AppFlow relies on it.

Keep the Lambda timeout and memory realistic for the size of the pages you return. If you plan to share the connector, package it for AWS Marketplace or share it across accounts through the registration process.

AppFlow is a poor fit when the job needs more than light, row-level transfers.

• Heavy transformation - joins, aggregations or custom logic belong in Glue, EMR or SQL.
• Sub-minute latency - schedules bottom out at one minute, so true streaming needs Kinesis or MSK.
• Database replication - use DMS for change capture from database engines.
• No API or connector - a system with no usable API needs a custom connector or another tool.
• Very API-limited sources - the source quota may cap what any tool can pull.

A good answer states the alternative too: Glue for transformation, Kinesis for streaming, DMS for databases, and a custom connector or Lambda when the app has no supported connector.

AppFlow flows and connections are Regional, so create them in the Region where you want to run them. A flow in one Region cannot be managed from another.

For a central data lake in another account, write to an S3 bucket in that account and grant the AppFlow service principal access in the bucket policy, plus KMS permission if the bucket is encrypted with a customer managed key. Where data must move between Regions after landing, use S3 replication.

Deploy the same flow templates to each account with CloudFormation StackSets so definitions stay consistent.

Remember that connections must also be created in each Region and account where flows run, so credentials should be managed centrally, for example through a shared secrets process, to avoid drift.

Layer several controls rather than relying on one.

• Mask or drop sensitive fields in the mapping so raw values never land.
• Encrypt with a customer managed KMS key for flows, connections and the S3 bucket.
• Keep traffic private with PrivateLink on supported connectors.
• Restrict IAM so only specific roles can create or start flows.
• Scan S3 with Amazon Macie to detect stray personal data.
• Audit with CloudTrail.

Do not forget the downstream copy. Even if the flow is secure, an analyst export or a public bucket undoes the protection, so apply the same controls to the whole path through S3, Glue and Athena.

Review the field list with the data owner before the first run, since removing a column later does not remove data already landed.

Mapped fields are fixed when you save a flow. If a field is renamed or removed at the source, the flow can start failing until you update the mapping.

If a field is added, it is skipped when you mapped fields explicitly. Using the option that maps all fields directly picks up new fields, but the destination schema must be able to accept them, which is easy in S3 and harder in Redshift or Snowflake.

Add an alarm on failed runs and review source release notes so you catch changes before they hit production.

For a controlled process, keep flow definitions in version control, and treat a source schema change as a small release: update the template, test in a sandbox account and then promote.

There are two clean options.

1. EventBridge rule on the end flow run report. Filter on the flow name and a success status, then target a Lambda function or Step Functions state machine.
2. S3 event notification on the destination bucket. New objects trigger Lambda, SQS or SNS.

flowchart LR
  AF["AppFlow run ends"] --> EB["EventBridge end report"]
  EB --> R{Rule matches flow and status}
  R --> SF["Step Functions or Lambda"]
  SF --> N["Glue job or notification"]

The EventBridge route tells you the run finished, including failures. The S3 route only fires when files actually appear.

Prefer EventBridge when downstream work must wait for a complete run, because S3 events fire per file and a multi-file run would trigger the next step several times.

Include the flow name in the rule pattern so one rule does not start work for unrelated flows.

AppFlow's SAP OData connector reads from OData services exposed by your SAP system. You choose the service and the entity to extract, then map and filter fields like any other source.

You supply the application host, service path and authentication, using basic or OAuth. If the SAP system is not reachable from the internet, set up private connectivity through a VPC endpoint service so traffic stays on your network.

Start with small entities and test pagination and filters before scheduling large extractions, because SAP performance limits apply.

Scope filters carefully. Pulling an entire large entity through OData can be slow and load the SAP system, so filter by date or company code and schedule outside peak business hours.

Idempotent means running the flow twice leaves Salesforce in the same state. Use the upsert operation with an external ID field that uniquely identifies each record in your source data.

1. Create an external ID field on the Salesforce object and mark it unique.
2. Include that column in the S3 CSV or source data and map it.
3. Choose upsert and select that field as the ID.
4. Set error handling to continue and review the S3 error bucket after each run.

A retry after a partial failure then updates existing rows instead of creating duplicates.

Avoid using the Salesforce record ID as the key when the source system does not know it. A separate external ID, such as the ERP customer number, lets both systems refer to the same record.

AppFlow writes to Snowflake through an S3 staging bucket and a Snowflake stage. It puts the files in S3 and then loads them into the target table.

You configure a Snowflake connection with the account, warehouse, stage and storage integration details. Then you choose the database, schema and table in the destination settings.

Snowflake supports private connectivity with PrivateLink, and failed records can go to an error bucket, so both security and troubleshooting are covered.

Set up the storage integration so Snowflake can read the staging bucket, and grant the AppFlow role access to the same bucket. Most first-time failures come from a missing bucket permission on one side.

Make sure the Snowflake table exists with compatible column types before the first run.