Skip to main content

The structure of an opportunity and project

Opportunities​

As explained before, BeLazy represents incoming assignments in the form of opportunities. It is important to understand the structure of an opportunity if you are working either with the Project Ingestion use case or the BMS Integration use case.

If you are implementing the Project Ingestion use case, you will be creating opportunities from workspaces. If you are implementing the BMS Integration use case, you may be listing incoming opportunities or not, but you will always work with projects, which are basically mapped opportunities.

The structure of opportunities​

Every opportunity in BeLazy is identified by:

  • a globally unique opportunity ID,
  • the globally unique identifier of the connection (in the case of BeLazy's own integrations) or workspace (if you implemented the integration according to the Project Ingestion use case) where this opportunity comes from,
  • and each opportunity belongs to a specific organization, which also has a globally unique organization ID.

These identifiers are generated by BeLazy and returned via the API.

Opportunities must have:

  • a name,
  • one source language,
  • and one or more target languages.

When you examine the API reference for the call that lists incoming opportunities, probably most metadata fields will be self-explaining. There are some unified fields such as created, endCustomer, deadline or link. However, each connector returns slightly different data, and these connector-specific extensions are represented under extraData. All metadata in an opportunity can be used to configure mapping rules and compose text fields (instructions) on the user interface, both unified fields and extraData fields.

Both pricing information and workflow step related information are represented as pricingItems under pricing. These can be representing

  • individual target languages (where the pricingItem differs in targetLanguage),
  • individual workflow steps, such as translation or review (where the pricingItem differs in workflowStep),
  • individual files or links, in other words translation assets (where the pricingItem differs in name or link),
  • additional receivables (where the pricingItem differs in a pricing-related value, such as unitValue or the analysis).

BeLazy can handle multiple types of units. If the unit is word, you can also work with analysis information. The analysis configuration is flexible: each line in an analysis needs to have a type (the name of the line), a quantity, a rate, which is the currency-expressed value (e.g. a 100% match is paid 0.03 USD per word), and a weight, which is a value expressed as a multiplier of the total word price (e.g. the compensation for a 100% match is 0.3x (or 30%) of the standard word rate applied).

Projects​

Once an opportunity is accepted, BeLazy converts it to a project. For more information about the lifecycle of opportunities and projects, see the next article.

If you look at the Get project call's response, you will see the similarity between opportunities and projects.

While a project in BeLazy has a globally unique project ID as well, it also refers back to the opportunity's ID that the project was created from.

Besides that, the main difference is that the project is a longer entity, as it contains three representations of the same data:

  • origin, which includes the fields as they were in the opportunity,
  • beLazy, which includes some unification and mapping of values that are important for BeLazy's display of projects on the interface, such as language codes,
  • destination, where the fields have mapped values.

You can safely ignore the beLazy representation, and primarily work with the destination values. If you are implementing the BMS Integration use case, the destination values will always comply with the values for your BMS that you see on the Manage my business management system page of the interface - the values of your system that you entered or uploaded via the APIs.

Unmapped data are still represented in origin. Probably you will never need to use these data in your BMS. Using Instruction mapping in the Edit automation dialog, users can map any origin field to an instruction field:

  • instructions_internal
  • instuctions_for_vendor

Projects and BMS projects​

BeLazy creates one project from each opportunity. If you use workflow mapping and bundling, multiple BeLazy projects may belong to the same BMS projects as different tasks or jobs.

Each BeLazy project has an internalBmsProjectId in the destination representation, and if this is equal, the tasks are bundled.

The mapped workflow appears in the project response in the Destination / mappedWorkflow value, with workflowName and jobs both appearing. The pricing items indicate which job or jobs on the destination side correspond to the source pricing item. You can find this information under the mappedWorkflowStep section. For each destination job, the relevant flags are true or false, and the indexInWorkflow value shows which is the ordinal number of the workflow step you need to insert this pricing item to (starting with 0). The flags are described under Mapping.

If you don't use bundling, it is enough to implement the logic to create projects in your BMS. If you use bundling, and you implement the BMS Integration use case, you need to also be able to append to existing projects.

Files in opportunities and projects​

Both opportunities and projects may have files attached.

You can only upload files to opportunities that you create. You can upload files into workspaces. Downloading files that belong to opportunities is not possible, because the downloading of files from the connections happens at the moment of project creation. However, you can see if an opportunity will or will not come with files by looking at the value of the hasFiles property of the opportunity.

Projects may also have files available at project creation time, indicated by the hasFiles property of the project. Use the Projects Api calls to list and download these files. Pay attention to the fileType which indicates whether it is a source file, a reference file or some other type. For a list of allowed fileTypes, refer to the documentation about the fileType property of the Add file to workspace call.

If you are implementing the BMS Integration use case, you will upload deliverable files to BeLazy that BeLazy will then deliver in the supported connections. If you are implementing the Project Ingestion use case, you will want to download these deliverable files. Both of these are possible using the calls of the Projects' deliverables Api.