Configurability

[drernie]

• configurable workflows
• multiple buckets (for different experiments)
• no auto-creation

[drernie]

Configurability

Motivation

The webhook currently assumes a single-tenant, single-bucket deployment: every eligible Benchling event is auto-packaged into one preconfigured destination. Organizations running multiple programs or experiment types need finer control over whether, where, and how packages get created. Today the only options are "everything, one bucket, always" or "off."

Requirements

1. Configurable workflows

Allow different Benchling entity types (e.g., notebook entries vs. registry entities vs. results) to map to different processing workflows, rather than one global pipeline.

• Per-entity-type routing rules
• Ability to exclude entity types entirely
• Sensible default workflow when no rule matches

2. Multiple buckets

Support routing packages to different S3 buckets depending on the source (e.g., per program, per project folder, or per entity metadata field).

• Bucket selection driven by configuration, not hardcoded at deploy time
• Deployment must be able to write to a set of allowed buckets (IAM implications — see Open Questions)
• Fallback/default bucket for unmatched events

3. No auto-creation (opt-out of auto-packaging)

Add a switch to disable automatic package creation, either globally or per workflow/entity type, so packaging can be an explicit, user-initiated action instead of an automatic side effect.

Proposed configuration sketch

auto_package: false          # global default; can be overridden per rule
default_bucket: my-default-bucket

rules:
  - match:
      entity_type: notebook_entry
      folder_prefix: "Program A/"
    bucket: bucket-program-a
    auto_package: true

  - match:
      entity_type: registry_entity
    workflow: metadata-only
    bucket: bucket-registry

(Format illustrative only — could equally be JSON, SSM parameters, or env config.)

Suggested phasing

1. Phase 1 — standalone webhook: implement config-driven routing (workflows, buckets, auto-package toggle) in this open-source repo, with docs and tests.
2. Phase 2 — product integration: wire the configurable webhook into the broader stack, including permissions/security hardening for multi-bucket writes.

Open questions

• Where does configuration live — deploy-time (CDK/env) vs. runtime (SSM/DynamoDB) vs. in-Benchling metadata?
• IAM strategy for multi-bucket writes: one broad role vs. per-bucket scoping?
• When auto_package is off, what triggers packaging — a Benchling button/canvas action, an API call, or manual?
• Should routing rules be validated at startup (fail fast) or evaluated lazily per event?

Acceptance criteria

• Auto-packaging can be disabled via configuration
• Packages can be routed to at least two different buckets based on rules
• Different entity types can trigger different workflows (or be ignored)
• Configuration documented in README with examples
• Test coverage for rule matching, bucket routing, and the auto-package toggle