How Organizations Use the Platform

The organization installs the free Salesforce managed package from AppExchange (or via a package install URL). Once installed, the Getting Started wizard appears automatically on first load. It walks through four steps: creating a Network Entity (the org's identity in the system), configuring default settings, setting up a Salesforce Site for public document access, and optionally connecting to Cloud Nimbus for cross-org sync.

Alternatively: Organizations that do not use Salesforce can sign up directly at cloudnimbusllc.com/portal and manage their work through the web interface. The portal handles bounty posting, claim review, and basic project management without requiring a Salesforce license.

Organizations manage work items through a Kanban board that reflects the full delivery lifecycle, not just a simplified “to-do / doing / done” model. Every work item progresses through:

All of these stages are billable. Developers log time against every phase. A 20-hour bounty might include 2 hours of discovery, 1 hour of sizing, 3 hours of architecture, 10 hours of development, 3 hours of testing, and 1 hour of deployment. The invoice shows line items for each.

The workflow is fully configurable via Custom Metadata Types -- organizations can define their own stages, transitions, and persona views. The default workflow type is “Software Delivery” with 37 stages, but other types (like “Loan Approval” with 8 stages) work identically.

When an organization has a work item they want help with, they configure how it should be delivered. The bounty posting form includes:

• 1Budget range and NTE ceiling -- the maximum budget for the work item. Every claim must include an NTE that falls within this range.
• 2Assignment model -- single developer (one exclusive claim), multi-developer competitive (all who deliver get paid), or team implementation (accept team proposals).
• 3Results visibility -- IP (private, results visible only to org) or public (results visible to community, builds developer reputation).
• 4Acceptance criteria -- a mix of automated (CI validates) and manual (human verifies) items that must all pass before acceptance.

Developers and teams submit claims through cloudnimbusllc.com/bounties. Each claim now includes the developer's profile, their proposed approach, NTE estimate with justification, estimated timeline, and relevant skills. For team claims, the proposal includes team composition and how work will be distributed across team members.

The organization reviews each claim's NTE against the budget ceiling, evaluates the approach's technical soundness, and checks the developer's (or team's) past performance metrics. For multi-developer bounties, the org can accept multiple claims simultaneously.

Submissions are verified against a two-part acceptance checklist. Not everything is CI/CD -- some acceptance criteria are manual (data migration verification, configuration, training documents). Both must pass.

For multi-developer bounties, the organization can compare submissions side-by-side, score each implementation, and accept all that meet the criteria. Rankings and quality scores feed back into the developer reputation system.

This platform is not just a contractor marketplace. Organizations can run their own internal employees on the same bounty system:

• 1Employees compete on delivery. Post internal bounties visible only to your team. Track who delivers on time, under budget, and at quality.
• 2NTE estimates still required. Even internal employees must estimate work. This creates accountability and builds organizational estimation skills.
• 3Auto-promote when SLAs slip. If an internal employee is at risk of missing their deadline, the system can automatically promote the bounty to the external marketplace for contractor pickup.
• 4Guard rails and ETA tracking. Automated warnings when at risk of falling behind. ETA calculations with dependency tracking show downstream impacts of delays.

Employees familiar with the repo have a natural advantage over external contractors -- and that is intentional. The system rewards domain knowledge while providing a safety net when internal capacity is not enough.

When the organization accepts a submission (all CI + manual criteria verified), the platform automatically triggers the Document Engine:

• 1Contractor Agreement with developer name, scope, compensation terms, and 8 standard clauses
• 2Invoice with line items from all lifecycle phases (discovery through deployment), total hours, rate, NTE comparison
• 3Email sent to the developer with PDF attachments + web view links, always CC'd to glen@cloudnimbusllc.com
• 4Invoice Approval -- client reviews in the portal, approves or disputes with line-item comments
• 5Payment processed via Melio (currently manual) or Stripe (future automated)

Feedback on the Organization Flow

Does this flow make sense? What's missing? What would you change?