CRM MVP
Whether the opportunity is still live or has been settled. Two values: open, or closed.
This is not the stage. The stage says how far the opportunity got. The status says whether it is still running. Most platforms collapse the two, and that collapse is the most common structural gap in this evaluation.
Every pipeline report has to exclude finished work by naming stages, so the report silently breaks the day somebody adds a stage or renames one. Open pipeline value, the most-quoted number in sales, becomes a figure that depends on the stage list being maintained rather than on the data.
Can the system say whether a given opportunity is open or closed, from the opportunity itself?
In full where it is an attribute of the record. A single field holding open, won and lost counts, and counts for resolution as well, because those three values carry both facts without loss: resolution is undefined while open, so the reference model has exactly three legal states and the mapping is one-to-one. A shipped boolean such as IsClosed also counts.
In part where the answer exists only as a structural property of the stage the opportunity sits in - a stage category, a stage type, a closed flag, a terminal probability. The fact is recorded, but the outcome taxonomy is coupled to the pipeline taxonomy, so renaming or reordering stages changes what history means.
Not at all where won and lost are stage names with nothing behind them.
Evidence standard. Recording that a platform lacks this requires an enumeration of the attributes the vendor ships on the opportunity object - an API object reference, a schema, a documented response body. A field-manager or customisation help article is not sufficient and must never be used for it. Pipedrive is the proof: it ships a genuine status attribute that does not appear in its own field-manager documentation. Where no enumeration is reachable the verdict is no verdict, not a failure.
An Act! opportunity carries its own Status box, listed among the opportunity's fields alongside and separate from Process and Stage. Status holds Open, Closed - Won, Closed - Lost and Inactive, so whether the opportunity is still live is read straight off the record without consulting the stage it sits in. Reopening is done by setting Status back to Open. The Opportunities tab filter bar exposes a Status list of check boxes, confirming Status is an attribute stored per opportunity.
The documented opportunity model has no open-or-settled attribute of its own: its fields are the milestone reference, value, expectedCloseOn, probability, closedOn, lostReason and similar. Whether the opportunity is settled is a property of the milestone it sits on, which carries a boolean named complete indicating that opportunities at that stage are closed. The list view offers an open-versus-closed filter, but the underlying fact is held on the milestone.
The opportunity record carries a Current State attribute holding Open, Suspended, Abandoned, Lost or Won. Insightly's own help text groups Open and Suspended as open states and the remaining three as closed states, so whether the opportunity is still live is read straight off the record rather than from the pipeline stage it sits in.
The deal object itself carries a status attribute taking open, won, lost or deleted, held separately from stage_id. Reading that one attribute tells you whether the opportunity is still live without looking anything up on the stage.
The ActiveCampaign deal object carries its own status attribute, documented in the API reference with the values 0 for open, 1 for won and 2 for lost. The help centre is explicit that this is separate from the stage: moving an opportunity to a different stage only repositions it in the sales process and leaves its status at open. Whether the opportunity is still live is therefore read from the record without any lookup against the stage.
The opportunity object itself carries a status_type attribute whose value is always one of active, won or lost, so whether the opportunity is still live is read straight off the record without looking up the pipeline status it sits on. The attribute appears in the documented create response alongside status_id and status_label.
The deal record carries a Status attribute, shown on the deal card and editable from the deal details panel, and Keap's help centre states that choosing Won or Lost from the Status dropdown closes the deal with that outcome. Dragging the card into a Won or Lost column on the pipeline board is documented as a second route to the same result, so the settled state is held on the deal rather than only implied by the column it rests in.
The opportunity holds only its Current Status, which is one entry in the pipeline's ordered status list. Whether that means the opportunity is still live is a setting on the status definition: the administrator ticks a closed-state option when configuring a status such as Sold or Lost. You have to look at how the status was configured to know whether the opportunity is settled.
The Opportunity object carries its own status attribute whose documented values are Open, Won, Lost and Abandoned, held separately from pipeline_stage_id. Open versus settled is therefore readable from the opportunity itself with no stage lookup.
The documented attributes of an Apptivo opportunity include Sales Stage, Probability, Amount, Close Date, Type and Lead Source, but no open or closed indicator and no separate status attribute. Sales stages themselves are created with only a name, a parent stage and a description, and the stage settings documented elsewhere cover entry criteria, exit criteria and activities on re-entry, so no stage-level closed flag, stage type or stage category exists either. Whether an opportunity is still live is carried only by the wording of the stage it sits in, such as a stage an administrator has named Closed Won.
The opportunity table ships a statecode column, labelled Status, whose options are Open, Won and Lost. It sits on the opportunity itself and is independent of the business process flow stage and of the separate salesstagecode picklist, so whether the opportunity is still live is an attribute of the record.
The deal object in folk's API reference exposes id, name, companies, people, createdAt, createdBy and customFieldValues, with no attribute for open versus settled. folk's help centre says a template of pre-made custom fields including Status is applied when a deal is created, but the vendor documents neither an option set for that field nor any platform meaning attached to its values, and documents no close action. Open versus closed therefore exists only as whatever a user types into an ordinary select field.
The opportunity itself carries an IsClosed checkbox. Salesforce's own guidance for locking down settled records writes a validation rule against PRIORVALUE(IsClosed) on Opportunity, so the open-versus-closed answer is readable as an attribute of the record. Stage values are separately typed Open, Closed Won or Closed Lost in Setup, and report Status filters read those stage types, but a reader does not have to look the stage up.
The API reference for the standard Deals object lists exactly six shipped attributes: name, stage, owner, value, associated_people and associated_company. None of them says whether an opportunity is still live. The stage attribute is of Attio's Status type, and a status value exposes only a title, is_archived, target_time_in_status and celebration_enabled, so looking up the stage does not yield an open or closed answer either. is_archived refers to the status option being retired from the picker, not to the opportunity being settled. Whether an opportunity is still running is carried only by the wording of the stage title, which the workspace can rename.
The Deals board records where an opportunity sits in a Stage column of monday's Status type; the seven shipped columns are Stage, Owner, Deal Value, Contacts, Expected Close Date, Close Probability and Forecast value, with no separate open or closed attribute on the item. Whether the opportunity is settled is instead a designation on the label: monday lets a board owner choose which labels define a status as done, and the API exposes is_done on each status label and on the item's status value. You must look up the label's configuration to know whether the opportunity is still live.
No enumeration of the properties Streak ships on the box object could be read, so absence cannot be evidenced. What is reachable is the write side and an admin article: the create-a-box endpoint documents name, stageKey, notes and assignedToSharingEntries, the edit-a-box endpoint documents name, notes, stageKey, followerKeys, linkedBoxKeys, assignedToSharingEntries, contacts, organizations and fields, and the support article on adding and deleting pipeline columns names Name, Stage, Assigned To, Contacts and organisations, and Notes as the columns present in every pipeline. A request-body parameter list is not the object's field list - it omits every read-only property - and a column-management article is the same genre of source that missed Pipedrive's shipped deal status attribute. Streak's own object model page enumerates nothing beyond key and boxKey.
The pipeline record carries Stage as a plain picklist value and nothing else about its state: the documented default fields for the Pipelines module are name, owner, company, related contacts, sub-pipeline and stage, amount, closing date and description, with no state attribute, and the API response for the module returns Stage as a string such as Closed Won. Whether that stage is live or settled is held in the stage's own metadata, where each picklist value carries a deal_category of Open, Closed Won or Closed Lost plus a probability and a forecast category. A pipeline is configured as a set of open stages and closed stages.
The outcome is applied to the opportunity itself, not read off its stage. The vendor documents marking a deal Won or Lost from the deal's own three-dot menu, or by dragging it into the Won or Lost drop areas below the board, and stage configuration carries only a name, guidance, expected days in stage and a default probability, with no closed flag or stage type. That the Lost by Stage report can still report the stage a lost deal was in confirms the outcome is held apart from the stage.
The stage side is now settled and carries nothing: the deal stage settings screen takes a stage name and a stage probability only, and the API's full Configuration section - retrieved in its entirety on this pass - returns id, name and deal_pipeline_id for deal stages and lists no forecast category selector anywhere among its twenty-one lookup endpoints, so forecast categories are not a shipped structure in this product. The record side could not be settled. The vendor's list of default deal fields runs Deal Name, Deal Value, Type, Expected close date, Closed date, Product, Payment status, Probability, Owner, Deal Pipeline, Deal Stage, Account, Related Contacts, Source and Campaign with no status or closed attribute, but that article describes the field manager rather than the API object, and a system attribute can exist outside the field manager. The Deals attributes table in the API reference remains unread, so a record-level status attribute can be neither confirmed nor ruled out.
Whether an opportunity is live or settled is a property of the pipeline stage it sits in. The vendor documents a status type selector on each stage when the pipeline is edited, with Deal Won, Deal Lost and Default as the choices, Default covering every stage still in progress. The public API schema matches this: the Status object, which is the stage, carries a type enum of DEAL_WON, DEAL_LOST or null, alongside name, order, colour, success_rate and the identifier of the list it belongs to. The stage must be looked up to learn the answer.
Status is its own attribute of the lead, taking Open, Won, Lost, Cancelled or Pending, and the vendor's import documentation lists Status and Stage as two separate mappable fields with Status defaulting to Open when left blank. Closing is described as changing the status, not as moving to a terminal stage.
Two default properties sit on the deal record, Is closed won and Is closed lost, each documented as true when the deal is in that state and false otherwise, and each set automatically by HubSpot. A deal reads as settled when either is true and as open when both are false, so the answer is on the record even though HubSpot derives the values from the stage's probability setting.
No enumeration of the attributes Vtiger ships on the deal record could be reached, so absence cannot be evidenced. Everything reviewed describes what an administrator can configure rather than what the object carries: the pipeline stage editor is documented as taking only a stage name, a probability, the roles allowed to set it and a colour, and the vendor's Standard pipeline runs New 5, Qualification 20, Need Analysis 30, Value Proposition 40, Negotiation 70, Ready to Close 90 and Closed 100 without containing the Closed Won and Closed Lost stages the vendor's own closing instruction tells users to pick. The forecast categories are a cumulative reporting rollup, not a per-stage type. None of that enumerates the deal's shipped attributes, and a stage-configuration screen is exactly the kind of source that would have missed Pipedrive's shipped deal status attribute.
The Deals record carries a mandatory Stage picklist and the standard field list holds nothing else that states whether the deal is live. Zoho puts the answer on the stage: stage-probability mapping assigns every stage a Deal Category of Open, Closed won or Closed lost, and the pipelines API returns a forecast_type on each stage of a pipeline with those same values. You have to look the stage up.