All about BF'D :
-Only for some of us who didn't know...
BF'D is an acronym for "Bring Forward Date" in the Canadian PR processing system. Usually our file moves from BF'D to BF'D, as it is the day/date next earmarked by our VO to check our file. This actually serves to eliminate unnecessary clogging of the system... that if there is nothing further to add in a particular file, the VO moves to another case file to work on, rather than holding onto the same one.
What happens on a BF'D
In simple terms it is the date that the file will be looked at [again], assessed, reviewed by your case handling officer at the CHC. S/he will check if anything is lacking, any further queries to be made [to you], any documents to be asked or if any decisive action is to be made/taken. Basically it serves as a 'Reminder Tool' to the case processing officer & that your file is not 'forgotten'.
Now, if the VO observes that something is lacking [that which was asked for], s/he will probably attempt to contact you on this BF'D day and mark another BF'D on your file. This depends on the subject of check [the all time phrase 'Case-to-Case' basis]. Sometimes, if the check report warrants, the VO might not give you another opportunity and take a decisive action. Note: The situation is fluid & no one can really provide a sanguine comment on it.
Will the file be 'only' looked at a BF'D
No. If something like reports, results, documents etc. [eg. background/security checks] comes to the CHC in between, your file gets opened and assessed. However, if nothing is received in between, you get another BF'D. Note once again: If they are waiting for something and it comes as expected then the file continues to be processed further, if not then the file will be next reviewed on the BFD 'only'.
An Example
Every time we get a letter/email from the CHC -it carries a 'time limit' to submit something, right? Say 45 days, 60 days or 90 days... the ending day of that time limit is our next BF'D. As an example, if the CHC sent you a medical request [alongwith the forms] on 02 Jan 2010; and it carries a 60 day's deadline -it means your file has been marked with the next BF'D of 01 Mar 2010.
However, if your medical results are received before the BF'D [01 Mar 2010], say on 05 Feb 2010 -your file will be further processed on that day itself [05 Feb 2010]. If the med results didn't come by earlier, then it will be opened on 01 Mar 2010 -the BF'D day.
How many BF'Ds we get
Some BF'Ds are 'routine', as exampled above. Then there are some which is either case generated or because of us. By 'case generated' I mean, [eg.] if one's Security Report is pending from an external agency -the VO gives a BF'D & waits. If the report comes in time, action is taken. If it doesn't, one gets another BF'D. And the situation continues...
By 'because of us'* I mean if the VO had asked us for a document [or a couple of them]. It is wise that we proceed to submit the document/s asap. Reason? The case moves faster [read: it'll open before the BF'D]. If we don't, s/he may try to contact us on the BF'D day & log another BF'D on our file [result: Delay/s].
Delays due to BF'Ds
As stated above, except the 'routine' ones, other BF'Ds do delay our process. At the least [best scenario] each BF'D would be a month apart. Some might be more. The ideal action on our part is to submit anything that has been asked for asap. That would negate a BF'D. However, there can be times that something we just might not be able to send asap. In that case we 'must' send it by the 'deadline' -that'd avoid another BF'D, won't it?
*Many Consultants [so called agents] erroneously advise us otherwise. Stating, "Oh you got the meds, don't worry you have time till 60 days to do it". That's a 'bull'. I'd advise -do it asap, if the speed of your case process matters to you.
This post I chose to write 'coz many members are either clueless about the BF'D issue or take it lightly. Which, albeit causes delays [without our actual intention]. Moreover, there are repeated queries on the subject in various threads. I hope this helped...
Qorax
