Dedicated CRM
Not a CRM - fails on status, resolution, expected close date, opportunity reporting
Core objects
In full
folk carries a genuine deal object, separate from contacts, with its own API resource and its own record: a deal is described as an object used to track opportunities or other outcome-driven items, and its native fields are name, people, companies, created at and created by. People and companies are separate first-class record types that exist independently of any group and can be referenced from anywhere, and people and companies can be linked to each other. A deal may be associated with one or more people and one or more companies, and neither association is required, so organization association is possible but not compulsory. Two activity-type objects exist and are distinct from notes: tasks, which carry a title, description, due date, assignee and a linked record and can be attached to a person, a company or a deal; and interactions, which record calls, meetings and messages with a date and an activity type. One real constraint applies to association: a deal lives inside a group and can only reference people and companies that are in that same group, and interactions attach only to a person or a company, not to a deal.
Source: https://developer.folk.app/core-concepts/deals, https://help.folk.app/en/articles/9790806-folk-data-model, https://help.folk.app/en/articles/15869200-tasks, https://developer.folk.app/api-reference/interactions/create-an-interaction
Verification: Verified
Pipeline stages
In full
Stage is not a native field on the deal object, but the stage construct folk ships is an ordered sequence rather than a bare label set. On creation folk applies a deal template of pre-made custom fields including a Status single-select, and the options of a select field are a stored, user-reorderable list which the vendor states is applied whenever records are sorted by that field, so the order lives on the field rather than only on a view. A pipeline view renders those options as left-to-right columns that deals are dragged across, with the value written back to the deal record, and the value is settable and filterable through the API's custom field values on create and update. There is no stage gating and no documented stage-entry timestamp.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://help.folk.app/en/articles/4991006-contact-fields, https://help.folk.app/en/articles/6044821-create-custom-pipeline-views, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/group-custom-fields/create-a-group-custom-field
Verification: Verified
Status
Not at all
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 center 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.
Source: https://developer.folk.app/api-reference/deals/update-a-deal
Verification: Verified
Resolution
Not at all
Nothing in folk's documentation records won as distinct from lost at platform level. There is no won or lost attribute on the deal object in the API reference, and the only place the vendor mentions such values is the dashboards article, which describes measuring the Status field a user added to a group using a value such as Closed or Won. That makes the distinction a user-supplied select option with nothing behind it.
Source: https://help.folk.app/en/articles/9867508-dashboards
Verification: Verified
Value
In full
The default deal template supplies a Deal value field.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/deals/get-a-deal
Verification: Verified
Scope of work
In part
The default template supplies no description, scope or products field.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/deals/get-a-deal
Verification: Verified
Expected close date
Not at all
The template supplies Closed at, recording when a deal actually closed rather than an expected date.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/deals/get-a-deal
Verification: Verified
Actual close date
In full
folk's help center states that the default deal template supplies pre-made custom fields including Closed at, so a date field for when a deal ended arrives without the buyer building it. It is an ordinary custom date field though: the API reference shows no native close date on the deal, folk documents no close action, and nothing in the documentation says the platform writes the value, so a person enters it.
Source: https://help.folk.app/en/articles/9552366-custom-object-deals-beta
Verification: Verified
Opportunity owner
In full
The default template supplies a Deal owner member field.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/deals/get-a-deal
Verification: Verified
Linked buyer
In full
People is a native deal attribute in the API, distinct from companies.
Source: https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/api-reference/deals/create-a-deal, https://developer.folk.app/api-reference/deals/get-a-deal
Verification: Verified
Record preservation
In full
A settled deal stays a record in its group and stays inside folk's own reporting. The dashboards article documents charts built on closed deals, including revenue by closing date, average deal value by closing date and revenue by closing date by assignee, and describes measuring the Status field for closed or won values.
Source: https://help.folk.app/en/articles/9867508-dashboards
Verification: Verified
Structured lost reasons
In part
A lost reason is held in a single-select custom field on the deal group, which makes it structured rather than free text, and folk's own dashboards documentation lists a suggested chart that breaks records down by lost reason so the sales process can be analyzed. The field is not supplied by the deal template and has to be created, but the field type and the reporting on it are both built in.
Source: https://help.folk.app/en/articles/9867508-dashboards, https://developer.folk.app/core-concepts/custom-fields
Verification: Verified
Email sync
In part
Email can be sent from inside folk - from a contact record, from a deal, or to a selection of records in a group - once a sender is configured, and messages sent from folk are logged automatically as interactions. Mail sent and received in the user's own client also reaches folk: connecting a Google Workspace or Outlook account imports emails and attaches them to the matching contact profiles in real time. The gap is on the reply side. folk states that replies from recipients land in the user's external mailbox, not in a folk inbox, and that the folk messaging inbox tracks outbound messages by status rather than holding inbound correspondence. folk also states plainly that actions performed in folk are visible only in folk and that there is no back synchronisation to the connected source. Certain classes of mail are excluded from import, including unread messages, messages older than three years, messages with twenty or more recipients and mailing list traffic.
Source: https://help.folk.app/en/articles/5779445-send-messages, https://help.folk.app/en/articles/5007315-track-interactions-emails-calendar-events-whatsapp-conversations, https://help.folk.app/en/articles/8170484-faq-sources-integrations
Verification: Verified
Calendar sync
In part
External calendar sync exists and it operates on the activity object rather than on a generic date field: connecting a Google or Microsoft account imports calendar events and files them as interactions on the matching contact profiles. It runs one way only. folk states that there is no back synchronisation with the source and that actions performed in folk are visible only in folk, and no vendor documentation describes creating or editing an external calendar event from within folk. Tasks carry a due date and generate in-app notifications, with no documented push to an external calendar. Declined events, events with twenty or more attendees, and daily or weekly recurring events are excluded from the import.
Source: https://help.folk.app/en/articles/5007315-track-interactions-emails-calendar-events-whatsapp-conversations, https://help.folk.app/en/articles/8170484-faq-sources-integrations, https://help.folk.app/en/articles/15869200-tasks
Verification: Verified
Schedulable activity types
In part
Activities can be scheduled without leaving folk in two ways. A task is created against a person, a company or a deal with a title, rich-text description, due date with optional time, one or more assignees and a public or private visibility setting, which covers internal operational work such as preparing a quote. An interaction can be logged against a person or a company with any date including a future one, which is how a meeting or call is put in the diary. Types are not user-definable. Tasks have no type field at all, and the interaction activity type is a fixed vendor-defined list covering call, meeting, message, coffee, lunch, event and drink plus a set of messaging-app values; the only user-supplied option is an arbitrary emoji rather than a named, reportable type of the buyer's own making. The fixed set does cover meeting and call, and tasks cover the task case, so the dimension is met but constrained.
Source: https://help.folk.app/en/articles/15869200-tasks, https://help.folk.app/en/articles/7012167-log-a-new-interaction, https://developer.folk.app/api-reference/interactions/create-an-interaction
Verification: Verified
Opportunity reporting
Not at all
One of the three exists, and the rule requires two. Native reporting is a dashboard builder pointed at a deal group, offering bar, grouped bar, stacked bar and pie charts and metric cards with count, sum, average and ratio formulas. Of the three required reports only an overall conversion rate is documented, and the vendor's own suggested version computes it from a user-defined status field rather than from a platform-level won and lost state, so the buyer creates both the field and the measure. No stage-to-stage conversion report is documented. No forecast or projected revenue chart is documented, and there is no first-class expected close date field for one to run on - the deal template supplies a Closed at date, which records when a deal actually closed rather than when it is expected to. The vendor also states that all charts display all-time data, so there is no period-scoped view of the numbers.
Source: https://help.folk.app/en/articles/9867508-dashboards, https://help.folk.app/en/articles/9552366-track-deals, https://developer.folk.app/core-concepts/deals
Verification: Verified