QuickPLS What the method does
An fsQCA specification states the cases, conditions, outcome, calibration and solution assumptions for one analysis. Naming and saving specifications makes it possible to distinguish a baseline from a sensitivity analysis. A changed specification must be calculated before its new results can be compared with the baseline.
Data and analysis in QuickPLS
Provide a case table or saved fsQCA project, named conditions and outcome, and the calibration and case decisions for each planned specification.
QuickPLS lets you organise fsQCA studies and named specifications. Use a meaningful name for each analysis and retain the completed result associated with it.
Follow a worked example
The following example shows the data, settings and decisions for one analysis. Use the linked practice files to follow it. For your own study, keep the procedure and choose the variables, model and settings that fit your research question.
Download memberships.csv to begin. It contains 10 rows and 5 columns. The example below identifies the variables to use, their roles and any rows to exclude; not every column is an analysis variable.
Keep the question and the decisions together
Suppose you decide that a score of 50 marks the crossover for high capacity. The crossover is the point where a case is neither more in nor more out of that set. The data file contains the score; it cannot explain why that boundary makes sense. Save the explanation with your research question, condition choices and reasons for leaving out any cases.
QuickPLS keeps three things distinct. A study holds your question and dataset. A specification is a named set of analysis choices, such as the conditions, outcome, calibration rules, thresholds and case decisions. A result records what the app actually calculated from those choices. Saving a new plan does not change an older result.
Choose and save the data first
Open the saved dataset you intend to study. It may contain raw measurements, existing set memberships or scores published from another analysis. A score is not automatically a set membership: decide what belonging to each set means before using it in fsQCA. Keep the original data so you can check every later decision against it.
Create your study in QuickPLS
Open the right dataset
Select the intended saved dataset and open Calculate… > Fuzzy-set Qualitative Comparative Analysis. Check the dataset before entering Study and named specification.
Write the question and name the setup
Under Study and named specification, fill in Study name, Research question and Specification name. The specification name should describe this particular set of choices.
Save the draft
Choose Save study draft. An older project may require a protected copy when study features are first added; later saves can stay in the current project. If a copy is returned, note its filename and continue there. Confirm the Study draft saved message.
Explain the sets and decisions
Open Set definitions and research decisions. Fill in the Set definition fields and Decision notes. Explain what membership means, where the membership values come from and why you chose the case rules and thresholds.
Keep a changed setup separately
For a deliberate alternative, choose Save as new specification and use a descriptive name. Reopen the project, select the saved named revision and check that its settings and notes are present.
Use names that tell you what changed
A name such as Theory-based anchors tells you how the starting calibration was chosen. Anchors are the reference values used to turn raw measurements into set memberships. If you have a sound reason to try a different crossover, save that choice under another name and explain it. You can then compare the two choices without guessing which settings produced each result.
If QuickPLS returns a protected copy, continue in that file and retain the original for earlier app versions. Check the copy’s location, save your edits and reopen it before relying on the saved history. Notes left in an unsaved form are not part of that history.
A saved specification may still be an unfinished plan. Open its completed calculation before quoting a solution or a fit value. The table below separates the information you have saved from evidence that an analysis actually ran.
On a small screen, swipe the table sideways to see every column.
| Output | How to read it | What to check |
|---|---|---|
| Study and named specification | The study records the question and cases; the named specification records one set of analysis choices. | A new name alone does not establish a different or reproducible analysis. |
| Source dataset and revision | Check the dataset and saved revision before previewing or calculating. | A similar filename or matching case labels do not establish identical observations. |
| Case choices | Record how you handle missing values, crossovers and exclusions before inspecting solutions. | An excluded case remains part of the research record; do not hide it by overwriting the source. |
| Saved study draft | A draft saves your plan. A saved result records a calculation that was actually run. | Do not present a saved draft or preview as a completed analysis. |
Follow one delivery question through several analyses
The exercise in memberships.csv asks which combinations of conditions go with successful delivery. Keep that question in the study. Save each defensible way of answering it as a named specification, including the conditions, outcome, membership definitions, included cases and calculation settings. A saved result belongs to the settings used for that calculation, even if you later revise the study.
This makes a practical difference when a supervisor asks why you left out a case or a reviewer asks for another frequency threshold. Frequency means the number of cases assigned to a condition combination. Delivery, frequency 2 explains the changed choice; Final 3 does not. Your colleague should be able to open the project and understand the sequence without asking you to reconstruct it.
Set up the starting analysis
The file contains ten labelled teaching cases. Let A mean capacity, B reach, C coordination and Y delivery. These meanings are invented for the exercise. The first eight cases have complete binary memberships: each value is fully in or fully out of its set. Case m09 has A = 0.5, exactly at the crossover; m10 is missing B. Explicitly exclude these two cases for this baseline. This is the exercise's stated decision, not a rule to discard every crossover case in real research.
In the comparison project, Outcome presence: named baseline studies delivery. Outcome absence: independently calculated studies its absence on the same included cases. These are different research questions. Keep them separate from a sensitivity check that keeps the delivery question but changes a threshold.
Save a baseline and one deliberate variation
After saving the two specifications, their names should be visible under the selected study. Reopen Delivery baseline and confirm frequency 1, then Delivery, frequency 2 and confirm frequency 2. Each completed calculation must still show the settings used when it ran.
Save the delivery question
Under Study and named specification enter Delivery combinations as Study name, the delivery question as Research question and Delivery baseline as Specification name. Choose Save study draft and confirm the saved message. Both names are required. If a protected copy is returned, continue in that exact file.
What you should see: The named study identifies the delivery outcome and its conditions.
How to read it: Use a name that distinguishes the research question from later settings.
Explain the baseline settings
Choose A, B and C as conditions and Y as outcome, with existing memberships and case_id labels. Record the exercise’s m09 crossover and m10 missing-value exclusions. Under Set definitions and research decisions explain the set meanings and these case decisions. Set frequency 1, consistency 0.80 and PRI 0.50, with no contradiction band, then save the completed choices.
What you should see: The baseline records calibration, thresholds and case decisions.
How to read it: The label alone does not preserve those choices.
Save and calculate the baseline
Save the baseline specification, inspect its truth table and run the calculation. Open the completed result. Check the included cases and identify the complete solution alternative you are reading.
What you should see: The baseline has a saved completed result.
How to read it: Changing a setup without running it does not change that result.
Save the frequency change separately
Change frequency to 2 and choose Save as new specification. Name it Delivery, frequency 2 and explain that you are checking support from more than one case per combination. Calculate this specification separately.
What you should see: The frequency change has its own named specification and calculation.
How to read it: Retain the baseline for comparison.
Return to the original analysis
Select the original named specification and its saved result. Confirm frequency 1. The later specification should remain a separate analysis choice; it does not rewrite the earlier calculation.
What you should see: The original result can be reopened with its own settings.
How to read it: Compare complete records rather than combining tables from different runs.
See why the frequency change matters
There are eight included cases and eight possible combinations of the three binary conditions. Each combination occurs once. Minimum frequency 1 lets every observed combination meet the case-support requirement. Minimum frequency 2 leaves none with enough supporting cases. The data and research question stay the same; the amount of evidence you require has changed.
At baseline, successful configurations are 101, 110 and 111, read in the order A, B, C. They simplify to A*B + A*C: capacity with reach, or capacity with coordination. Solution consistency and coverage are both 1. Each pathway has raw coverage 2/3 and unique coverage 1/3. The solution guide shows the case counts behind these values. The saved frequency-2 result is empty; it does not provide zero-valued replacements for those fit measures.
Write the reason when you make the choice
A useful note says what changed and why. For example: Frequency 2 checks whether any combination has more than one included case. Each combination occurs once in this exercise, so we expect none to meet the new requirement. That note gives a reader more information than calling the setting stricter.
Keep a reason written before calculation separate from an observation made afterwards. You can record that the frequency-2 result was empty after opening it. If the decision itself was made after inspecting a result, say so. Exploratory work can be reported clearly without describing later decisions as a plan made in advance.
Name a changed question as well as a changed setting
Changing Y to its absence asks a different question. Replacing existing memberships with a calibration of raw scores changes what membership means. Selecting another dataset may change the observations. Give each specification a name that identifies the actual change; Alternative model does not tell the reader which of these happened.
Before comparing outcome presence and absence, check that both calculations refer to the same original observations and compatible case decisions. Matching labels alone are not enough. In a robustness exercise, you may deliberately change which cases are included. Describe that choice and its reason, so the comparison shows the change instead of hiding it.
Find the reason an older result looks different
Start with the result's saved specification and project filename. A result can be correct for an earlier setup even when the form now shows different choices. Use the checks below before changing the data or repeating the analysis.
On a small screen, swipe the table sideways to see every column.
| What you notice | What to check | What to do |
|---|---|---|
| The result does not reflect an edited threshold | Whether it belongs to the earlier saved specification | Calculate the new revision and select its result explicitly. |
| A reopened file lacks recent specifications | Whether work continued in a protected project copy | Open the returned copy at its recorded path; retain both files until their contents are confirmed. |
| Two named results appear to disagree | Whether they use presence and absence of Y | Compare their questions and outcome definitions before comparing expressions. |
| A comparison rejects apparently matching cases | Whether datasets and original observations really match | Use the intended saved source and explicit case decisions; matching labels alone are insufficient. |
| A report still shows the old expression | Which saved result and alternative the report selected | Prepare a new report from the intended result rather than changing its title. |
Describe the baseline and the changed choice
Use the example paragraph as a pattern for the Methods section. Then report what each calculation found. Keep the outcome-absence analysis separate because it answers another question; the frequency comparison examines the support for the original delivery analysis.
On a small screen, swipe the table sideways to see every column.
| Specification | Question or change | What the example shows |
|---|---|---|
| Outcome presence baseline | Explain Y with frequency 1 | A*B + A*C; solution consistency 1 and coverage 1 |
| Frequency sensitivity check | Require two cases per configuration | No observed configuration meets the frequency requirement |
| Outcome absence | Explain the complement of Y separately | A different question requiring its own calculation |
Example Methods wording
We saved a baseline delivery specification using existing memberships, eight included cases, frequency 1, consistency 0.80 and PRI 0.50. A separate specification increased minimum frequency to 2 while keeping the selected conditions, outcome and case decisions unchanged. The two specifications were preserved with their own results.
Make the saved history understandable to a colleague
You could report the exercise this way: The baseline covered all three successful teaching cases. Requiring two cases per configuration left no observed configuration with enough support. The baseline therefore depends on accepting configurations represented by a single case in this dataset. This explains the sensitivity without suggesting that frequency 1 is right for every study.
Close and reopen your saved project. Find each specification by name, then locate its data, outcome, case choices, settings and completed result. Explain which analysis studies delivery and which checks the effect of requiring more cases. If you cannot tell them apart, improve their names and notes before exporting.
- Name the research choice that changed.
- Keep the original CSV and the returned protected copy easy to identify.
- Explain the changed choice in Methods and its consequence in Results.
- Check that each report selects the intended saved calculation.
Check the saved file and the saved revision
Save changes before closing the project. If you import another file, check its actual observations and columns. Similar filenames or matching case labels do not prove that two imports contain the same data.
Practise with a copy of the guided study
Download the synthetic Guided fsQCA project and keep an untouched copy. Its saved teaching results come from the 1.03.07 sample programme. Use them to practise naming another specification and returning to the original. These supplied results are not a new calculation in your installed Store app or a replication of a published journal dataset.